shooting from the hip here, but also in the spirit of re-indexing the “compensation/incentivization” question for third parties involved, we could get over this hump by issuing a nominal grant to third party operators with time-locked LDO.
the thinking here is that this would incentivize third party operators to perform their job well in order to harden one of Lido’s core functions and over time increase the value of their future gov stake and/or reward.
also, afaict thus far it looks like consensus leans towards “yes, let’s increase the set” while there still context to flesh out on “should we allow third parties (as in not Lido NOs) in?” and if so “what is the incentive model for third parties?”
“should we allow third parties (as in not Lido NOs) in?”
In general I think the optimal composition is some mix of NOs that participate in Lido + third parties. This accomplishes the goal of reducing the possibility of malicious NO collusion while performing oracle duties while still maintaining an overall trusted element within the oracle set until such a time that trustless oracles could be implemented.
“what is the incentive model for third parties?”
I think there are a few incentives here for third parties to participate, setting aside possible financial ones.
Including third parties into the operator set can increase the transparency of protocol operations to onlookers, and there are various third party organizations that fulfill roles of “neutral participants” in various ecosystems who basically provide value by participating in furtherance of keeping everyone honest. While this isn’t a direct benefit to said third party except in the “I’m doing a good thing” way, the third party may have an interest in the proper operation of Lido (e.g. be an LDO holder) and therefore benefit from this indirectly;
It’s a way to build up a reputation by participating in the running of relatively simple but yet critical infrastructure and duties for one of the largest DeFi protocols;
It’s a way to build up reputation, visibility, and trust with Lido and Lido users in case the third party may wish to collaborate with the DAO or bring attention to other services the org provides.
Would it make sense to require NO to run oracles in the future? As part of the requirements to become a NO? Or is it hard enough to onboard quality NO as is?
Spire is interested in becoming an operator for the Lido oracle set as a trusted third party. We provide permissioned oracles on other chains and welcome the opportunity to support Lido’s growth. Thanks!
We are pleased to announce that we are finally ready to provide the community with a shortlist of potential new oracles for onboarding. We are very excited about this process and are committed to decentralization by expanding the set of oracles with third parties.
We onboarded 6 oracles on the testnet. And we are happy to propose the shortlist for further votes to expand the set on the mainnet.
Now we have 5 oracles and 3/5 quorum. The proposal is to add 6 new oracles and set quorum as 6/11.
We are now ready to take the steps to expand the set on the mainnet. To do this, we plan to launch a snapshot vote in the very near future and then, if the snapshot vote is supported, launch Aragon-vote for onboarding.
If the community has an opinion on this proposal, feel free to share.
How the current oracle 3-of-5 concensus works? All 5 oracles send report tx and the oracle contract only accepts the first 3? or the software uses an offchain picking algorithm to choose 3 of 5?
The shortlist shows non-NO oracles will be onboarded this time. Happy to introduce non-NOs into Lido eco. However, All the 6 candidates are not the direct stakeholders to Lido. How to keep them honest when those 6 are chosen to report beacon stat together.
thanks @satBalwyn; for your first set of questions I think you will find answers through the hyperlinks in the original post.
re: alignment—I can speak for Rated; we’ve been through 2 grants rounds with Lido which we have completed successfully. so far we’ve gotten compensated in LDO (we asked), haven’t sold a single token and holding to a 60% drawdown on avg (see ratedw3b.eth). on balance, marked to market, this means that we have paid to do the work.
to be clear: we approach token based comp as accumulating agency and aligning incentives between ourselves and folks that we work with, with a long term view.
for myself, context again in the original post.
more generally, given that there will be 11 operators whose versions of reality will be medianized, the fact that the role is pro-bono, as well as the fact that the incentives that all net new operators are fairly well aligned with Lido and the NOs that make it up, I would say that the “risk” that you raise is tolerable—at worst, and on balance the proposed set up is a net improvement for the DAO.
Offchain daemons send txs with the reports, on-chain contract receives the first three matching one another to quorum, and that triggers the report finalization along with rebase.
Good q! The teams are pretty ecosystem-aligned as-is, so on the surface of it seems ok to have 6 new members. Other options we can explore are either onboarding, say, 4 new members now & some more later on, or 2) raise the quorum not to 6/11 but to 7-8/11. WDYT?
Could we separate the onboarding into 2 waves this time.
In Wave1, we first onboard 3rd parties to apply the quorom 5/8 (at least 2 old oracles have to report). After certain time (1 mth or 2mth?), introduce the other 3 and use the quorom 6/11 in Wave 2.
BTW, one idea for long-term plan. Since some existing NOs are interested in running oracles, could we consider the regular rotation between the NOs who are running oracles and who want to run. For example, 1 NO oracle is rotated per mth.
Can’t see improvement in safety here. If you’re considering new oracles as potentially malicious (that’s what blockchain people do in general) — getting to higher quorum is a safer option. Two waves is just “we ask you to wait before going rouge” imo. As for the tech tests, all teams are running oracle software on the testnet and are running those fine.