In general I am happy to support this proposal and Cherry Crypto has voted in favour on Snapshot.
However this is after a considerable amount of time diving into the discussions here and other related documentation to better understand the module and the potential risks involved. This effort was likely higher than other participants’ thresholds for well-informed participation, some of whom may be silently voicing abstain due to the lack of familiarity with oSnap or how UMA oracles currently work.
A first thought, for @middleway.eth, is whether we should outline a more formal proposal framework when proposing changes that will impact the governance process. Given the high stakes involved—governance being the highest authority of a DAO and its treasury—some more formal structure around describing the change, rationale, intended benefits, potential risks, (see next section) etc. would put this information more up front.
The framework should end with a requirement for the master governance / process doc (afaik for CowDAO it is this forum post) to be updated if the proposal is passed.
Second, for @againes, appreciate the proposal and your detailed follow-up posts. However, it would have been helpful if additional material for oSnap (one pager, small deck, demo recording, etc) was originally attached to illustrate and go over examples. In particular I would have liked to have seen more info on the risks that @middleway.eth described, as well as (non-exhaustive and complementary/duplicative to @middleway.eth’s post):
- Happy flow
- Happy flow in case of any infrastructure failing
- Happy flow in case of a good proposal whose tx reverts
- “Forced flow” in case the multisig is required to intervene and force an action through
- Dispute flow, for bad proposal
- Dispute flow, for good proposal
- Attacks related to spam (eg. trying to pass invalid or malicious proposal, fatiguing UMA voters, etc) or DOS (continually burning bond, forcing revotes, etc)
- Related, I did not understand definitively what happens in the case of a correct proposal that becomes disputed. Assuming the multisig is not called into action, would this entail a re-vote on Snapshot?
And then on the UMA side, a bit more on:
- How the proposal bot works (what does it look at and compare, how does it detect good/bad proposals)
- How community members could participate in running such services if they wanted to, as fallback (or competitive) infrastructure
- How UMA voters collect evidence and determine truth (are they running a similar bot, etc)
- Curiously, why is Auryn’s proposal for the rules statement not valid? In my opinion it is better formulated and easier to understand than the original and other UMIPs suggest very arbitrary wording is possible?
I apologize this feedback is coming in relatively late given the advanced notifications around this discussion in the forum. Hopefully late is better than never as this is intended to help future processes and discussion, and on UMA’s side, should create re-usable material for future users.