Withdrawal Credentials Exits Based On A Generalized Message Bus

This would require that the LSD protocol holds the pre-signed (never expiring) exit messages from the validators right? That doesn’t seem like a good, or safe, long term approach. Thoughts?

1 Like

This would require that the LSD protocol holds the pre-signed (never expiring) exit messages from the validators right? That doesn’t seem like a good, or safe, long term approach. Thoughts?

Yes, agreed on all points.

It’s an imperfect solution, but it’s better than nothing, and it’s quick. If we can prioritize a full solution, then let’s definitely do that, but if not, I think this is an easy step forward in the meantime.

We can limit the risk a lot by limiting the amount of stake going to a permissionless/unvetted operator if we can solve the white label operator/identity problem. Withdrawer-initiated withdrawals are not a blocker to meaningfully increase the number of operators in Lido, the identity problem is. Allocating the majority of stake to them without a introducing major bond would be problematic without withdrawer-initiated exits.

The big concern here is centralization risk. Having protocol functioning directly dependent on yet another body that has to handle the secrets is not great. Removing people from the loop is preferable.

1 Like

Agreed. I’m being involved with conversations on Lido side to help with this as I’ve been working on a model for ordering entering and exiting of validators for a couple hundred hours now. Hopefully can help to bring some ideas to what your team already has progressing.

I think there is a path to diversifying Lido operators even without solving the identity problem, and without requiring collateral to the extent of limiting capital efficiency meaningfully. I’ve been talking to Izzy about it.

Agreed, this is not an ideal solution long term. Though I do think it’s worth weighing up the time that would be required for an EIP to go live to do this properly, if that does end up being a solution that’s approved and added to the codebase. If it’s 1+ year, an interim solution like above, where Lido would centralize the keys here might be an acceptable option when the alternative is to wait 1+ year (potentially, just a guesstimate), or wait likely longer for the Nethermind solution to identity.

Personally, I find centralization of keys with Lido in the interim to be an acceptable tradeoff, but I know many would disagree. My main reasoning for this is that the current system requires a worse centralization, which is with the reliance on node operators to act faithfully. I think it would be helpful for more of these conversations to be had in public, so that Lido users can weigh-in on tradeoffs here.

Thanks for your response Vasiliy.