Voter dapp claim rewards bug

By August 11, 2020DApps
Click here to view original web page at github.com

Description

I have experienced an issue with the voter wherein claiming rewards submits a transaction that results in no UMA being sent, despite correctly voting. On a second transaction, rewards are correctly claimed.

After investigating this issue it turns out that I am not the only one to experience it. @claytonroche has reported the same issue as well as a few people in Discord saying that they needed to send two transactions to claim rewards.

Reproduction

This issue has only occurred once for me and I have not been able to re-create it. The flow was as follows:

  1. The first time I loaded it up to claim my voting rewards it did not show that I had any rewards to claim (claim rewards button did not show).
  2. I then clicked “search all past rounds for unclaimed rewards” and then clicked claim rewards when the button showed up.
  3. I signed and submitted the tx that the UI gave me but I got no rewards from it; 0 UMA transferred.
  4. After this, I hard re-loaded the page and this time it showed me the claim rewards as soon as it loaded (like it normally does) and this tx gave me my rewards as expected.

Expected Behavior

The first transaction should not be sent. The dapp should never enable the user to send a tx that does not claim any rewards.

Additional Context

I have de-coded the transaction data for my claim rewards function call. The redacted object is shown below:

{
    "name": "retrieveRewards",
    "params": {
        "voterAddress": "0x000NOT-DOXING-MYSELF0000",
        "roundId": "9231",
        "toRetrieve": [
            {
                "identifier": "0x41646d696e203800000000000000000000000000000000000000000000000000",
                "time": "1595095182"
            },
            {
                "identifier": "0x41646d696e203900000000000000000000000000000000000000000000000000",
                "time": "1595095665"
            }
        ]
    }
}

Decoding @claytonroche's transaction data of the same error yields different output, with his claim rewards call being sent against the first identifier (0x41646d696e203800000000000000000000000000000000000000000000000000).

These identifiers translate to Admin 8 and Admin 9, both of which happened on Saturday, July 18.

Therefore it appears that the voter dapp incorrectly tried to claim rewards for past round that had already had rewards claimed.

Leave a Reply