Proposal for Enabling the Timely Vote Credits Mechanism on Solana Mainnet

Proposal for Enabling the Timely Vote Credits Mechanism on Solana Mainnet


Validators have learned that they can maximize vote credits earned by reducing the likelihood of voting on a dead fork by delaying votes long enough to see which fork is most likely to win (or has already won). This has led to varying strategies employed by a host of validators that induce different degrees of delay (“vote lag”) in voting. This delay in voting results in slower confirmations and finalizations of blocks which directly impacts the speed at which Solana processes transactions. A solution to this problem was devised with the Timely Vote Credits (TVC) feature, which proposes that votes be awarded a variable number of credits, with faster votes receiving more credit than slower votes. This provides an economic incentive to vote quickly, which counterbalances the advantage to waiting to survey forks before voting.

The Timely Vote Credits feature was proposed in the Solana Improvement Document number 33 (SIMD-033). It is fully implemented by two features:

  1. 7axKe5BTYBDD87ftzWbk5DfzWMGyRvqmWTduuo22Yaqy (“replace Lockout with LandedVote (including vote latency) in vote state #31264”) which upgrades vote accounts to a new structure which has room to record the latency of votes in preparation for using those latencies to determine vote credits. This feature has been enabled on testnet since epoch 586 (22 epochs at the time of this writing), and enabled on mainnet since epoch 585.

  2. tvcF6b1TRz353zKuhBjinZkKzjmihXmBAHJdjNYw1sQ (“use timeliness of votes in determining credits to award”) which enables the vote program to begin recording the latencies of votes and then use this latency when awarding vote credits, such that votes with latency 1 or 2 earn 16 credits, with each subsequent slot of latency earning 1 fewer credit, down to a minimum of 1 credit awarded for any vote.

The second feature is only available in the 1.18 Solana Labs/Agave branch and so can only be activated on mainnet-beta after this release is present on a sufficient quorum of stake, as per the normal feature enabling rules.


The following testing has been performed to ensure the safety and correctness of the implementation:

  1. Unit tests were added to the Solana Labs/Anza node implementation that demonstrate that the feature works as expected in a wide variety of cases, including awarding the expected number of vote credits:


  1. A test cluster was created to test the effects of TVC in operating nodes. A write-up of the results of this test has been created


It is proposed that the Timely Vote Credits (TVC) feature as described by Solana Improvement Document 33 (SIMD-0033) shall be enabled on the Solana mainnet-beta cluster according to the following steps:

  1. Feature tvcF6b1TRz353zKuhBjinZkKzjmihXmBAHJdjNYw1sQ shall be enabled on the Solana testnet cluster for a period of no less than 8 epochs, with any issues that are discovered fixed in a way that does not violate the purpose of the feature as described in the SIMD.

After this point, TVC will have been fully enabled on testnet for no fewer than 8 epochs.

  1. Feature tvcF6b1TRz353zKuhBjinZkKzjmihXmBAHJdjNYw1sQ shall be enabled on the Solana mainnet cluster.

After this point, TVC will be fully enabled on mainnet-beta.

Voting Process

The vote will be conducted as follows:

  1. A discussion period will commence, during which all validators should participate to ensure that all concerns are addressed.

  2. Stake weight collection period will then commence. The stake weights that will be used for voting will be captured and published, and all validators will have an opportunity to verify these weights.

  3. Voting tokens will be distributed to the validators according to the stake weights gathered in step 2. Each lamport of stake will receive one vote token. Thus a validator who had 125,000 SOL stake, which is 125,000,000,000,000 lamports, will receive 125,000,000,000,000 vote tokens. It is expected that in practice, vote tokens will be referred to after begin divided by 10^9, so a validator will have 513.71625 “vote tokens” if they have 513.71625 SOL stake.

  4. Three token destination accounts that correspond to three voting choices will be created: a Yes vote account, a No vote account, and an Abstain vote account.

  5. Validators will have the remainder of the vote token distribution epoch plus 3 additional epochs in which to vote by sending vote tokens to these addresses (there is nothing preventing a validator from sending some of its tokens to more than one address, although this can only serve to reduce the effectiveness of their vote should they choose to do so).

  6. After the voting period is complete, if the sum of the Yes votes is equal to or greater than 2/3 of the total sum of Yes + No votes, then the proposal has passed.

All of the announcements about this process, including the announcement of the vote tally account addresses, will occur in both the Governance category of the Solana Developer Forums and the vote-timely-vote-credits channel of the Solana Tech Discord.

Timeline (each step starts at the beginning of the first indicated epoch and completes at the end of the last indicated epoch):

  • Epoch 588 - 594: Discussion period
  • Epoch 595: stake weights captured and published, discussion/confirmation of stake weights
  • Epoch 596: voting token distribution, vote addresses created, voting begins
  • Epochs 596 - 599: voting continues and completes
  • Epoch 600: voting is finished and the resulting tally determines the outcome


It is imperative that validators participate in discussion about this proposal. The best place is on the Solana Tech Discord’s vote-timely-vote-credits channel, where active discussion has occurred already. In addition, discussion may occur on the Solana Developer Forums and also ad-hoc in places like Twitter, Reddit, etc. All discussion wherever it happens is encouraged, but it’s even better if the discussion is kept relatively concentrated in one place so that most participants can see most of the discussion without redundancy. For this reason, the preferred discussion forum is the vote-timely-vote-credits channel on the Solana Tech Discord, and any discussion that starts outside of this forum should ideally be directed to continue in the Discord.


vote-timely-vote-credits Solana Tech Discord channel: (and then select the channel)


This is a great approach to fixing a loophole in the rewards mechanism on Solana and has gone through a lot of scrutiny showing it works as intended and is safe to enable. I support this feature.


I participated in the dedicated cluster for testing these features. To my knowledge, the feature is safe and works as intended.

I also agree with the spirit of this proposal: patching the loophole that is being exploited to gain extra credits by failing to participate in consensus (and simply echoing whatever consensus is reached by the rest of the cluster).


Spectrum Staking fully supports TVC feature and the voting process.


Juicy Stake fully supports this feature. Let’s incentivize network performance and not APY


Aurora Validator will vote yes for timely vote credits. Fast confirmations, low fees and high throughput are key to ensuring the success of Solana. Thank you for helping get a fix for this loophole Zantetsu.


We at Stronghold Validator fully support this feature


Edgevana is supportive of TVC and will be voting yes.


Great initiative! Stake City will support.


The Firedancer software includes support for Timely Vote Credits.
The implementation is not yet public.


Chainflow appreciates the work @zantetsu and others have done to bring this to a point where it can be voted on. We’re also glad to see that testing was done prior to the proposal being posted.

It seems to us that fully activating Timely Vote Credits on Mainnet is a net positive for the Solana community and for this reason we support it. The proposed timeline feels sufficient as well, i.e. long enough to generate an appropriate level of discussion, while not causing an unnecessary delay.

We also note that the voting mechanism suggested is the same one used for the first signaling vote. And finally we’re glad to see this vote further aligning the in-development governance process with the more established SIMD process.


Jito Labs is fully supportive of this proposal and will be voting yes once live. Thanks to Zan and others for pushing it for so long.

  • Brian

The SolDev validator will vote yes once live as well. Thanks to everyone involved.


Thanks for this important proposal. Everstake will support TVC feature.


Great job man, fully supports this proposal. LFG

1 Like

The token distribution based on stake weights has been captured. Please review the voting procedure and validate the distribution file here: GitHub - laine-sa/tvc-gov


Great work, thank you for this proposal.

We are happy to support it at and have voted Yes.

We believe Timely Vote Credits will make Solana more efficient and contribute to building a fairer validator ecosystem.


Great work! Thanks for all the effort it took to make this proposal. T-STAKE Systems fully supports this proposal. Unfortunatly I cannot vote yet as I just started my mainnet validator, just wanted to show my support :+1:


Very good​:+1::+1::+1::+1::+1::+1::+1::+1::+1::+1::+1:

The voting period has ended in the last slot of epoch 599 (slot 259199999) with the following results:

     YES  |   51.7500%  |    191499201395655382
      NO  |    0.8400%  |      3108403106138704
 ABSTAIN  |    0.7000%  |      2596234841182772

    CAST  |   53.2900%  |    197203839342976858
  SUPPLY  |  100.0000%  |    370034545735897184

The required threshold for this proposal to pass was 66.66% of all YES + NO votes. The final tally is 98.4% YES, therefore the proposal to approve and enable Timely Vote Credits has passed the governance vote.

Enabling of the TVC feature gates is subject to final timing by Anza engineers based on network adoption of minimum supported versions and overall network health.