It’s been very cool to watch this take shape since my original POL LST post way back in March. It all seems so obvious in hindsight! I’m strongly in favor of moving this forward because I believe it will achieve all of the intended improvements.
well done on the spec @pete!
I want to add a few more risks that I see, so we can properly prepare for them:
- centralization risk for voting: unlike ETH, POL is also used in governance. So a POL LST doesnt handle exactly like an ETH LST or impact the ecosystem the same way. so if there is any one LST project which is really big holding, they may have too much governance power in the future. We can limit this by having healthy competition in the LSTs that we publicly support or nicely asking LST projects to limit (both are social layer). Maybe there is a better onchain to do this like have a max validator size, of say 10M POL or something. As each validator essetentially has its own unique “Delegated POL” token, those would be easier for an LST developer to delegate to different delegates.
- If slashing is implemented, I believe LSTs can handle that without much complexity and it should be their responsibility. However, there’s also a potential situation where a validator intentionally commits a bad slash-able action, and the instead of getting slashed decides to sell all their tokens instead. Perhaps some sort of timelock on exiting/unstaking from the token? even if its very short like a few minutes, might increase security. I will think about this one more.