Hello Everyone,
I want to give an update on the Yambassadors Silo / Voting with Treasury UMA initiative.
In the initial post I made I laid out the following tasks that I would perform:
- I have already created a working 2-key contract and provided the basic code to interact with it via on-chain transactions. I will coordinate with @ethe to will send a test amount of UMA (est. 2 UMA) to the contract in the upcoming on-chain transaction as well as send some of the UMA (est. 1 UMA) back to the treasury. This will test both sending and retrieving.
- With the UMA left in the contract, I will vote on an UMA vote and confirm it works.
- I will create documentation around UMA voting best practices and link to the relevant existing documents. I will publish this to the forum, and coordinate with having it added to github and other documentation resource locations for the DAO.
-
The test UMA transaction was carried out in the last on-chain transaction, with 2 UMA sent to the contract and 1 UMA removed back to the timelock. You can see that transaction here: Ethereum Transaction Hash (Txhash) Details | Etherscan
-
The next step is to vote with the UMA in the 2-key contract from my own wallet. I completed the first part of that today, voting in a dispute about the opening weekend box office revenues for the movie Elvis. I still need to complete the second step of voting, which is a reveal phase, which I will do either later this evening or tomorrow. I will describe the full methodology below.
-
Documentation is the next step, and I figured I would start by writing up my thoughts here first, seeing if there is feedback, and then turn them into more formal documentation and figure out the best spot to post it. So here goes:
Voting on UMA
UMA Specifics and some Theory
UMA is a decentralize oracle protocol in which different kinds of questions can be asked, with UMA voters serving as the ultimate oracle of truth as to the answer. It uses an “optimistic” model, which means that questions can be answered and the answers are assumed correct unless disputed. If an answer is disputed then it goes to the UMA voters who determine whether or not the dispute and/or original answer proposal are valid.
UMA voters are responsible with determining answers to these disputes, and the way the incentives work is to force coordination and discussion to determine the outcome that the majority will vote for. It is important not to gloss over this. UMA incentivizes guessing correctly (with the crowd) with the assumption that the majority will choose the accurate or true answer. If you vote for the winning choice then you earn the UMA incentives. If you don’t then you don’t earn incentives, but there are no other negatives.
Robert Leshner, founder of Compound sums it up nicely:
The person deciding on how the DAO should vote with it its UMA should take this into account. The optimal strategy to maximize rewards is very clearly to coordinate in a way that assures you vote with the crowd. This mainly entails going over to the UMA discord and talking with other voters there to determine what the schelling point (what the crowd decides) is and going with it. The nice thing is that it means that everyone should be trying to determine what everyone else is going to vote for and should be very willing to share their opinions about what to vote for.
Details of my vote
This is where things are going to get a little technical, so if you don’t care about exactly how it works then this section probably isn’t for you.
The vote is an interesting one because it is both cut and dry and also confusing. Lets dig in.
Here is the UMA discord channel where this was discussed: Discord
The question that needs an answer is " Will ‘Elvis’ gross more than $45 million domestically on its opening weekend?" You can see the full specification of the question and contract here: UMA - Optimistic Oracle
The UMIP, which defines the logic for how this question should be answered is located here:UMIPs/umip-107.md at master · UMAprotocol/UMIPs · GitHub
The transaction that initially proposed to answer the question is this one: Polygon Transaction Hash (Txhash) Details | PolygonScan
You can see in the transaction data that it was answered as p4 which can be seen as -57896044618658097711785492504343953926634992332820282019728792003956564819968 which means that it is an early request. At the time of the request, it seems that the data was not yet available so this is the correct answer at the time.
Why someone would submitted this answer is still a mystery to me since I see no advantage to proposing a “too early” answer. It essentially keeps the question open and I assumedit would only be answered by the DVM given a dispute, and not before a dispute. I have asked about this in the UMA discord and will update this post when I learn why this may have been done.
Either way, this “too early” answer was then disputed in this transaction: Polygon Transaction Hash (Txhash) Details | PolygonScan. Although the too early answer seems like a silly thing to propose, it does not appear that it is an incorrect answer. In fact, it doesn’t seem like it is possible to disprove it without knowing when exactly the final data was posted.
So it seems mostly clear cut that the dispute is incorrect and the correct answer is the original p4 answer given by the proposer. Once this dispute is settled, the actual answer can be proposed, since the data needed to answer the question is now available, and that answer will eventually be NO.
What an adventure. Hope I got it right. I’ll let you know shortly.