Report on Voting with UMA

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:

  1. 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.
  2. With the UMA left in the contract, I will vote on an UMA vote and confirm it works.
  3. 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.
  1. 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

  2. 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.

  3. 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/ 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.


I voted correctly! After the post yesterday, the reveal phase started and I revealed my vote. Once all votes were revealed (there is a 16 hour window), the final outcome is set. The voted upon correct answer was p4.

For this vote, we earned a negligible amount of UMA (0.00356789 to be exact, but that is only voting with 1 UMA token). I claimed it successfully this morning and it now lives in the 2-key contract. You can check it all out here: DesignatedVoting | Address 0x8348c5EC31D486e6E4207fC0B17a906A0806550d | Etherscan

In terms of testing scope, I think I have completed all the tasks I laid out:

  • Create 2-key contract
  • Send UMA to contract from treasury
  • Remove UMA from contract to treasury (in Timelock, but same thing)
  • Vote successfully
  • Claim reward successfully

Assuming everyone agrees, I think we can go ahead with moving the rest of the UMA tokens into the 2-key contract and proceed to vote with them. I will create a snapshot vote to do this.

I still need to write some documentation about the process and how voting works.

And I now need to make a proposal for voting in all future UMA votes as that is outside of the scope of this testing phase.