Hey there,

I've had a look through the slashing proposal and wanted to share my thoughts.

The team's done a solid job breaking this down into three main parts:

First up, there's the Leader Schedule Migration (#180). It's pretty straightforward - moving from node IDs to vote accounts. Makes sense as a starting point and sets everything up nicely for what's coming next.

The verification system (#204) looks good. Love that they're starting with duplicate block violations before tackling the more complex stuff. The fact that there's already some code in the SPL repo shows they're making real progress.

The actual slashing mechanism (#212) ties it all together. Good to see they're planning to run it through governance - gives everyone a chance to weigh in.

A few things I reckon would be worth considering:

• Could use more detail on how the penalties will be calculated
• Would be good to see how they'll handle any disputes that come up
• Some concrete testing criteria

Overall though, it's a solid proposal. The step-by-step approach makes sense, and it's good to see they're not trying to rush everything in at once. The dependencies between each phase are clear, and the governance involvement keeps everything above board.

I'd say it's worth moving forward with. The team seems to have their heads around the technical challenges, and the structure looks sound.

Keen to hear what others think about it.

Looks good to me. Do we have metrics on how often duplicate blocks are submitted? Is that happening at all? I seem to remember one incident in particular long ago, but aside from that I'm unaware if that's something that is actually happening. I'm more excited about slashing for voting violations, but understand we need a proven and trusted framework in place first.

Looking forward to this - great work!

Thanks for the work here Ashwin, for specific feedback on #212 should I comment here or there? I'll start by posting here:

• My general thoughts for some time have been that for an initial slashing implementation we should avoid ever touching the principal (meaning any existing lamports in a stake account), and only penalize in two ways: freeze the account, preventing withdrawal or change of ownership (could permit or even force deactivation though), and slash future rewards from the vote account. With increasing severity of the offence the duration of the freeze and rewards slashing increases, this is not somewhat similar in thinking to lockout behaviour in voting. if you commit an offense you're locked out from participating in rewards. The major attraction is that it doesn't create the major fear of loss of principal, rather it is just a loss of rewards and access for a limited period.
• Stake accounts are pretty fungible these days, it is not necessary to wait for an epoch boundary to unstake, this can be achieved in the secondary market by converting to an LST such as jitoSOL or blazeSOL for instancen. As a result waiting for an epoch boundary provides ample opportunity for stake to "flee" a validator that has an impending slashing event. It would be desirable that a verified offense results in an immediate action, such as freezing the stake account (can't change withdraw authority = can't deposit to LST) and possibly force deactivation (perhaps necessitating splitting the account to force deactivate 10% of a validator's stake for instance - or just move those lamports from delegated_stake to balance of the same account, akin to how MEV is deposited into the stake account without being delegated, but this may be more complex).

Freezing and lack of rewards can theoretically be extended indefinitely, providing a significant deterrent as a first step, with the freezing of stake accounts a validator is unable to simply start a new vote account and ask stake to move (or move it itself if its a private validator). An option is to also slash a percentage of rewards, so stakers continue to earn rewards but at a reduced rate, e.g. 90% of normal rewards and unable to undelegate for 20 epochs.