Hi, Nemo here, Lido Alliance contributor, let me try to cover answers to the questions bellow.
Are there any relevant peer or competing solutions that were compared / considered with regards to the proposal and the various parameters (allocation, KPI, security)?
-
When Lido contributors first started exploring preconf this spring/summer, only bolt and commit-boost were actively building in the space (or at least on the radar)
-
Lido DAO also gave a grant to commit boost, more details here: Commit-Boost Grant Proposal for Lido Community
-
During Zuberin, Bolt was the only team with ready-to-show prototypes. During & after the conference, they proved very cooperative and aligned with the Ethereum ethos + super receptive on feedback and design implementation suggestions
-
Lido Alliance is open to anyone that demonstrates Ethereum and Lido alignment (from the perspective of both code security and security practices overall), as well as GOOSE alignment in particular. Given a high degree of collaboration with the Bolt team early on, as well as their development and security processes proving to be satisfactory by Lido’s standards, we didn’t approach other teams that started building in pre-confs in the meantime.
-
No, allocation was not explored with other projects as we didnt have other applicants.
-
The KPI metric was made based on a discussion with the Bolt team, where we attempted to find a fair middle ground for both sides and strive for the win-win scenario. If Bolt is successful in their work, the assumption is that a lot of validators will be happy to opt-in.
-
Also, the Bolt team will be next to fill this out: [Proposal] PERCH: Protocol Evaluation and Request Coordination Hub for coordination for testnet colab
-
There will be one more proposal in the future to endorse Bolt tech, assuming everything goes as planned/agreed upon during the testnet period
On your KPI threshold and success metric: How is this going to be measured? Might have missed something on the technical side here but naively seems this can be gamed / end up with scenarios where if MEV reward >> Bolt collateral a operator might choose to get collateral slashed but end up in profit from rewards, and still maintain KPI ratio as it seems to just be the % of who opted in?
Interesting note, but such behaviour doesn’t seem reasonable:
-
Even in status quo, a Node operator may attempt to «steal» huge MEV, but we can detect these actions and impose strict consequences (up to and excluding the NO from the operator set)
-
With preconf software installed the proposed scenario may occur, however such significant MEV would either end up in Withdrawal credentials and be distributed among holders, DAO and NO’s (so no economic rationale to do so) or NO’s might also try to «steal» MEV, except in this case along with the existing reputational harm, they would also lose Bolt collateral.
Generally we assume that NO’s acting in such a manner is not economically rational (longterm, even exorbitant MEV < daily rewards from Lido), not to mention the reputational harm NOs would face as legal entities.
more details about calculation you can also find here
1. Other than Chorus One, are there any other validators that are on both the Ethereum Curated Module (Node operators registry) list as well as in any of your funding rounds? Declaration around this would further add transparency towards incentive alignment and monitoring.
Nope, only Chorus One
Hope this helps 