SIMD-0357: Alpenglow VAT implementation #357

wen-coding · 2025-09-12T05:23:50Z

No description provided.

jstarry · 2025-09-12T05:42:30Z

proposals/0357-alpenglow_validator_admission_ticket.md

+  - If several validators have exactly the same amount of stake and including
+  all of them would exceed the 2,000 limit, then all of them are excluded
+
+5. Subtract 1.6 SOL from the corresponding vote identity account in the list of


what happens if the vote identity doesn't have 1.6 SOL? We should also probably restrict vote identities to being a system owned account so that we don't unintentionally subtract lamports from a locked stake account or something

The proposal right now is to exclude those accounts without sufficient funds from staked validators in the new Epoch, so they can't vote or be leaders.

AshwinSekar · 2025-09-12T15:32:19Z

proposals/0357-alpenglow_validator_admission_ticket.md

+- a BLS pubkey
+
+- at least 1.6 SOL VAT fee plus the necessary storage rent amount for a new
+epoch in its corresponding identity account


any reason we choose identity vs vote account?
Implementation wise it seems more complex as multiple vote accounts can specify the same identity

No please, I'm in favor of the current design. All rewards go into the validator's identity and no sol goes into vote account (unless there's commissions). It'll be a pain to keep 1.6 sol/epoch in vote account.

We already have a precedent that validator's identity account pays vote tx fees so I agree we should keep it as the identity. But @AshwinSekar makes a great point that we need to figure out what to do if multiple vote accounts specify the same identity account and the account doesn't have a high enough balance to pay for all of them.

Yeah the identity account was mostly chosen because currently all rewards go there, so if someone has enough rewards to cover VAT they don't ever need to worry about transferring money into vote accounts.

Per the current algorithm, if multiple accounts use the same identity account, the fees will be deducted in descending stake order (then descending pubkey). If you have 3 vote accounts using the same identity but your fee can only cover 2, then the two higher staked accounts get in while the third one is out.

If people are okay with that behavior, I'll specify it in the SIMD.

@jstarry I added the same comment below :) I'd fix 1-1 mapping at epoch boundary.

Also, are you implying we should send rewards to vote account instead in Alpenglow?

Wait, I think @tigarcia explained to me a lot of people don't actually have the private key to their vote accounts any more, because we didn't really have any operations requiring that.

Are we implying we need everyone to recreate vote accounts?

Okay, scratch my false statement above, I think choosing vote account is fine. The only caveat is we need to move block rewards and prio fee destination from identity account to vote account, then people don't need to constantly top up their vote accounts for VAT fees.

we need to move block rewards and prio fee destination from identity account to vote account

yes but keep that out of this simd. it's a separate optimization and doesn't need to muddy vat

Okay, I changed this SIMD to deduct VAT from vote account, we can put rewards into vote account in another SIMD.

AshwinSekar · 2025-09-12T15:33:57Z

proposals/0357-alpenglow_validator_admission_ticket.md

+- at least 1.6 SOL VAT fee plus the necessary storage rent amount for a new
+epoch in its corresponding identity account
+
+When the staked validators for a new epoch is calculated, the leader will


this affects all uses of staked validators - turbine, leader schedule etc correct? would be good to specify.
Also any behavior regarding staked validator overrides - if I have it set does it create a 2001 spot or replace a validator.

Today this is not the case. The turbine tree is generated with a list sorted by (stake, identity), while the leader schedule is generated from the same list sorted by (stake, vote). So the lists are currently different. I'm of course highly in favor to unify, but that's prob a separated turbine-specific simd?

Hmm do we have staked validator overrides for mainnet or testnet? I suppose staked validator overrides should be considered before we do the sorting, so it doesn't create the 2001th spot, it kicks one validator in the 2000 list out.

Err, I think currently Turbine gets node stake from the same list we are calculating here, so yes Turbine will be affected, unless we intentionally give Turbine a different list. Is there a reason we don't want unity here?

That said, theoretically we should never hit this 2000 limit, so we should be fine...

The core issue is just that SIMD-0180 was done only for leader schedule and not for turbine tree. So now we seed the two randomizations with different lists. What I wanted to say is that I'm in favor of unifying, but maybe we should just do an independent simd to re-align turbine tree with the new list.

For the record, we discussed this at the SLC dev meeting, I believe the current consensus is that it's okay to unify the list, since we should almost never hit the 2000 limit, this should be fine and unifying simplifies the reasoning.

so just to clarify this affects all usages of validator stake / total stake in the protocol? Or could you specify exactly when we use this filtering vs the "normal" stake view?

This will affect all usages of validator stake / total stake in the protocol.

proposals/0357-alpenglow_validator_admission_ticket.md

AshwinSekar

woops accidentally approved, meant to comment

0x0ece · 2025-09-12T16:01:00Z

proposals/0357-alpenglow_validator_admission_ticket.md

+
+3. The calculation goes through all vote accounts and filter the following:
+
+  - Contains at least 1.6 SOLs as balance in its corresponding identity account


Currently, the same identity could be used on multiple vote accounts. 😭

My strong preference is to enforce that, for every epoch, there's only 1 vote account per identity (if there's more, we can pick the vote account with higher stake). This simplifies a ton of other things.

Alternatively, we'd have to handle the case where the identity has enough sol for some vote accounts but not for all, and we'd have to agree on which ones we'd include and exclude.

Would be ideal if we can enforce 1-1 mapping of vote account to identity account, less confusion. Let me chat with Foundation folks to see whether there is any legitimate use of multiple vote accounts for one identity account.

- Per [discussion](solana-foundation/solana-improvement-documents#357 (comment)) in VAT SIMD, we will enforce the restriction that each node identity should be 1:1 with vote accounts, no need to test other cases - Use standard gensis config creation to set epoch_stakes

proposals/0357-alpenglow_validator_admission_ticket.md

Co-authored-by: Trent Nelson <[email protected]>

t-nelson

getting pretty close now. probably time to get another review from the firedancer team

t-nelson · 2025-12-02T00:04:46Z

proposals/0357-alpenglow_validator_admission_ticket.md

+
+The validator admission ticket is a mechanism translating the current cost of
+voting into a similar economic equilibrium for Alpenglow. By charging every
+voting validator 1.6 SOL per epoch, it replaces the current voting fee at ~2


nit: we repeat 1.6 SOL throughout the document. replace with simply VAT other than this first instance

Sure, I kept the first one and the one in New Terminology, removed all other ones.

t-nelson · 2025-12-02T00:09:18Z

proposals/0357-alpenglow_validator_admission_ticket.md

+6. Record the VAT fee subtraction in the bank, move the lamports directly into
+the incinerator account.
+


not a change for the simd, but wherever we're tracking the agave implementation, we need to emit an appropriate RewardInfo entry for each of these debits in the corresponding block. it is unacceptable to lose this accounting information

Hmm, I did a quick search for RewardInfo in Agave, I don't see a case where the reward is negative. Would it break someone's tool if we suddenly have a negative number in RewardInfo? Should we add it to some other entries?

the RewardInfo::lamports field was converted from u64 to i64 specifically to record rent debits (gh indexing of old labs repo is busted, so i can't find it). likely this has been removed since rent collection was disabled

Okay, in that case I'll just add it to this SIMD so we don't forget to do it. Changed.

implementation details do not belong in simds. this is not an agave todo list

Okay, removed. Just for my education, which team is supposed to do this?

the field is not under consensus. it's only metadata

Sounds good, any more comments on this SIMD?

simd-bot · 2025-12-05T03:24:17Z

Thanks, lidatong!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (t-nelson, sakridge, or bw-solana)
Missing approval from: Firedancer (ptaffet-jump, topointon-jump, 0x0ece, lidatong, or ripatel-fd)

bw-solana

Approving from Anza side

simd-bot · 2025-12-17T21:52:36Z

Thanks, bw-solana!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (t-nelson, sakridge, or bw-solana)
Missing approval from: Firedancer (ptaffet-jump, topointon-jump, 0x0ece, lidatong, or ripatel-fd)

iabdulin · 2025-12-17T22:04:52Z

/merge

simd-bot · 2025-12-17T22:04:55Z

iabdulin Only the PR author (wen-coding) can run the /merge command.

⚠️ Status: Cannot merge yet

Missing approval from: Anza (t-nelson, sakridge, or bw-solana)
Missing approval from: Firedancer (ptaffet-jump, topointon-jump, 0x0ece, lidatong, or ripatel-fd)

wen-coding · 2025-12-17T22:06:51Z

/merge

simd-bot · 2025-12-17T22:06:55Z

wen-coding ⚠️ Status: Cannot merge yet

Missing approval from: Anza (t-nelson, sakridge, or bw-solana)
Missing approval from: Firedancer (ptaffet-jump, topointon-jump, 0x0ece, lidatong, or ripatel-fd)

iabdulin · 2025-12-18T18:27:00Z

/merge Please work some Christmas magic!

simd-bot · 2025-12-18T18:27:05Z

iabdulin Only the PR author (wen-coding) can run the /merge command.

✅ Status: Ready to merge

wen-coding · 2025-12-18T18:30:38Z

/merge

simd-bot · 2025-12-18T18:30:45Z

✅ Merge successful! wen-coding's PR has been merged.

wen-coding added 2 commits September 11, 2025 22:23

Add Alpenglow VAT implementation proposal.

e27c10e

Fix proposal number and address lint warnings.

7fd816f

wen-coding changed the title ~~Add Alpenglow VAT implementation proposal.~~ SIMD-0357: Alpenglow VAT implementation Sep 12, 2025

wen-coding added 2 commits September 11, 2025 22:36

Fix typo.

40650f8

Fix more typo.

2f1d755

wen-coding requested review from AshwinSekar and jstarry September 12, 2025 05:38

jstarry reviewed Sep 12, 2025

View reviewed changes

AshwinSekar previously approved these changes Sep 12, 2025

View reviewed changes

AshwinSekar reviewed Sep 12, 2025

View reviewed changes

0x0ece reviewed Sep 12, 2025

View reviewed changes

Clarify that VAT fee burned will reduce bank capitalization.

bb4441f

github-actions bot mentioned this pull request Sep 15, 2025

Upstream Updates - Mon Sep 15 00:16:53 UTC 2025 smartcontractkit/chainlink-solana#1343

Open

wen-coding mentioned this pull request Sep 24, 2025

Simplify StakedValidatorCache test. anza-xyz/alpenglow#468

Merged

lidatong reviewed Oct 8, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

Fix typo.

7ff88dd

bw-solana reviewed Oct 14, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

proposals/0357-alpenglow_validator_admission_ticket.md Show resolved Hide resolved

Address pr comments.

5163eda

bw-solana reviewed Oct 20, 2025

View reviewed changes

wen-coding added 2 commits October 20, 2025 14:13

Address pr comments.

5b7d9e6

Fix urls.

f43b842

AshwinSekar reviewed Oct 23, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

The commission is actually paid to vote account, not identity account.

d0e32dd

rogerANZA reviewed Oct 24, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

rogerANZA reviewed Oct 24, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Show resolved Hide resolved

rogerANZA reviewed Oct 24, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

rogerANZA reviewed Oct 24, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

rogerANZA reviewed Oct 24, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

rogerANZA reviewed Oct 24, 2025

View reviewed changes

proposals/0357-alpenglow_validator_admission_ticket.md Outdated Show resolved Hide resolved

wen-coding and others added 7 commits November 26, 2025 11:55

Update proposals/0357-alpenglow_validator_admission_ticket.md

8e7168b

Co-authored-by: Trent Nelson <[email protected]>

Update proposals/0357-alpenglow_validator_admission_ticket.md

297632e

Co-authored-by: Trent Nelson <[email protected]>

Update proposals/0357-alpenglow_validator_admission_ticket.md

ee0bd39

Co-authored-by: Trent Nelson <[email protected]>

Address pr comments.

b59d279

Address pr comments.

13ff6cb

Remove "valid vote account" section.

d4dc90c

Make linter happy.

7d56cc5

wen-coding requested review from bw-solana and t-nelson December 1, 2025 20:48

t-nelson reviewed Dec 2, 2025

View reviewed changes

Replace 1.6 SOL with VAT.

a4ca4f7

wen-coding requested a review from t-nelson December 2, 2025 19:37

wen-coding added 2 commits December 2, 2025 18:11

Specify that RewardInfo needs to be updated.

0a8b2b8

Remove RewardInfo information.

3f7bc10

wen-coding requested a review from lidatong December 4, 2025 19:53

lidatong approved these changes Dec 5, 2025

View reviewed changes

bw-solana approved these changes Dec 17, 2025

View reviewed changes

simd-bot bot merged commit 34f4001 into solana-foundation:main Dec 18, 2025
2 checks passed

wen-coding deleted the vat_simd branch December 18, 2025 18:31

github-actions bot mentioned this pull request Dec 22, 2025

Upstream Updates - Mon Dec 22 00:18:52 UTC 2025 smartcontractkit/chainlink-solana#1405

Open


		3. The calculation goes through all vote accounts and filter the following:

		- Contains at least 1.6 SOLs as balance in its corresponding identity account

		6. Record the VAT fee subtraction in the bank, move the lamports directly into
		the incinerator account.

SIMD-0357: Alpenglow VAT implementation #357

SIMD-0357: Alpenglow VAT implementation #357

Uh oh!

Conversation

wen-coding commented Sep 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wen-coding Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0x0ece Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

AshwinSekar left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

t-nelson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

wen-coding Sep 12, 2025 •

edited

Loading

0x0ece Sep 12, 2025 •

edited

Loading

AshwinSekar left a comment •

edited

Loading