UMA-GYSR Delegator Pool Proposal

[neondaemon]

Name of Project: UMA-GYSR Delegator Pool

Proposer: Deadcoin, Neondaemon, Pumpedlunch, Robbie (SuperUMAns) ; Devin (GYSR/Passage Labs); Bananachain (SuperUMAns, B Labs)

Proposal Summary To set up a UMA-GYSR pool where small holders of UMA tokens can receive proportionate rewards by staking into a delegated pool.

Project Description

Part A: Description of issue

Background:

UMA’s Voter dApp 2 (https://vote.uma.xyz) introduced a two step model:

1. staking rewards irrespective of engaging in any voting activity, and
2. voting

If engaged in staking only, the staker is awarded rewards at a flexible APY rate, currently at around 25%. However, when not engaged in voting and/or voting incorrectly the staker is penalised and the staked principle fractionally reduced (“slashing”). In consequence, if a staker votes correctly they will receive a proportion of this slashed UMA.

For its predecessor “dApp 1” no staking option was available, nor any penalisation (bar UMA inflation) for inactivity or incorrect votes. However, rewards were only distributed when the vote cast was correct. Likewise, gas reimbursement was only available if the vote was revealed (i.e. publicising the vote cast), irrespective of the vote being correct or not.

Problem:

If as a staker you are an active voter AND vote correctly then the dApp will work well for you. If you do not engage in voting, or vote incorrectly, you are penalised and your gains will decline to 0 over time.

This need for constant voting activity, however, involves advancing ETH gas expenses on multiple occasions during the monthly voting windows, irrespective of prevailing gas levels at the time. These ETH gas fees are reimbursed on a monthly basis, subject to a reveal transaction which also requires a gas transaction on mainnet.

From an economic and process point of view this system favours big token holdings who have the necessary skill set and time to engage in the above process. It is neither suited to engage an existing group of smaller UMA token holders nor does it provide sufficient incentive to attract, engage, build and motivate active, diverse and vibrant communities.

At the time of writing (July 2023), 44 out of 141 (31%) of voters are unprofitable, with gas costs often being higher than their staking returns (see UMA Staker Stats spreadsheet for data). There is no economic interest for those voters to continue to stake since staking and voting costs those accounts money. This creates sell pressure on UMA as small holders unstake and sell, do not engage in staking, or voting, or consider investing in UMA in the first place. All the more so as other tokens offer passive income opportunities. These users are also likely to leave the UMA community as they no longer hold the token and feel priced out of the protocol.

The issue of small voters has been recognised in UMAs policy:

“While reduced participation by smaller voters does not affect the game-theoretical properties of the protocol, it is inconsistent with UMA’s fundamental mission: Universal Market Access. Furthermore, prominent and helpful members of the UMA community are being discouraged from participating. While the protocol may not technically require their participation, the growth of the ecosystem benefits from their contributions in the form of mindshare.”

Proposed solution:

To mitigate this, we propose to build delegated voting pools so small holders can deposit their UMA and automatically receive their share of the staking rewards

• without the need to vote, and
• without the need to pay any gas fees

At the same time, this will

• decrease the amount of gas rebates Risk Labs is required to pay
• increase the amount of UMA staked, and
• facilitate community retention by incentivising a wider adoption of UMA

Value Add to UMA

By adopting delegation, Risk Labs would be able to significantly reduce its individual gas reimbursements (possibly also cutting down on admin) while at the same time putting itself in a position of scaling its outreach.

Further, while smaller voters do “not affect the game-theoretical properties of the protocol”, they play a role in securing the OO. A robust set of human voters is critical to the dispute resolution process to discourage collusion and corruption of the OO. This set of smaller voters is akin to validators traditionally enriching and diversifying the blockchain ecosystem.

In addition, it could provide UMA with a platform from which to build and grow a vibrant community by incentivising its members while engaging purposefully by spinning up multiple competing voting pools.

Finally, this staking pool can be instrumental for UMAs Brand Ambassadors to attract and engage newcomers, thereby rewarding and creating a new group of UMA voting token holders.

This promotes Universal Market Access (UMA) in its truest form, ensuring an inclusive and decentralised environment.

Part B: Proposed execution

To address the above issue we propose the following approach:

• develop a prototype + testing with selected participants
• develop a scalable beta product + engage in first onboarding
• Implement off-chain voting
• conduct marketing activities

High Level Workflow (Phase One)

Technical requirements

• Optional whitelist of users and max amounts
  • Useful during trial phase so only known small holders can participate
• Configuration
  • UMA token address (immutable)
  • Voter contract address (immutable)
  • GYSR pool address (immutable)
  • Lockup period (immutable or read)
  • Delegate address (changeable)
  • Delegate fee (immutable)
  • Max individual stake size
  • Max total pool stake size
  • Min position size for delegate
• Stake
  • Receive UMA, compute effective share of voting pool
  • Deposit UMA into voting contract
  • Set share/rate for user in GYSR Assignment staking module
• Unstake
  • Queue unstakes for batch withdraw request
  • Finalise batch unstake and return share of UMA
  • Trigger reward distribution
• Rewards/slashing
  • Proxy should be subject to increased magnitude of both rewards and slashing
    • (as a function of fee)
  • Controller can compound globally
  • Controller can distribute rewards with GYSR reward module fund
  • End user can choose to claim or compound reward distributions

Total Budget Requested
The total budget calculated and requested by the SuperUMAn + Passage team for phase one and two:

24,000 USD + audit

(to be funded and payable in UMA, the USD value stated throughout this document is the applicable exchange reference at payment)

Budget components, (detailed tasks below under heading “phase one”)

• Developing a proxy voting contract and factory: 10,000 USD
• Unit and integration testing of new contracts: 5,000 USD
• Estimated price range for audit: 5k-15k USD
• Project preparation, management, testing, user UI, marketing: 9,000 USD

Calculation of phase three is left open and will be clarified once the prototyping, as described under “Phase one” and “Phase two” below, is completed.

Timescale

• Development of Proxy Voting contract and factory: 1-2 months
• Unit and integration testing of new contracts: 1-2 months
• Pilot a small test pool on testnet: ~ 2 days
• QA and/or audit of new contracts: 1 month
• Pilot a small test pool on mainnet: ~3 months
• Rollout and marketing in parallel with mainnet testing: 5 months

Deliverables

• Smart contract source for Proxy Voting and Factory
• Unit and integration test suites for new smart contracts
• Security audit report
• Report on pilot program process and results
• Marketing, collateral and campaigns including social media

Phase one (prototype + testing)

• Development of Proxy Voting contract and factory
  • build proxy voter smart contract (60 hours)
  • build factory contract (20 hours)
  • integrate proxy voter contract with GYSR and UMA core protocols (20 hours)
  • 10k USD request by Passage for this work (100 hours total)
• Unit and integration testing of new contracts
  • write unit test suite for proxy voter (20 hours)
  • write unit test suite for factory (10 hours)
  • write integration test suite w/ UMA voting contract (10 hours)
  • deploy/integrate contracts on testnet (10 hours)
  • 5k USD request by Passage for this work (50 hours total)
• Build a user UI:10 hours (SUDAO)
• Pilot a small test pool on testnet
  • Conduct test transactions and check overall operability (queueing+withdraw period)
  • Draft a user manual
  • trial period: ~2 days
• Preparation of marketing, collateral and campaigns including social media
• Pilot a small test pool on mainnet
  • invite a few known UMA holders to test the system (~10 deposits and ~5 withdrawals)
  • trial period: ~3 months

Phase two (beta + onboarding + completed product)

• QA and/or audit of new contracts
  • estimate ~500 lines of solidity total
  • 2 files in scope
  • will have dependency on external protocols (GYSR, UMA)
  • codebase will have thorough testing
  • can get specific quotes once a prototype codebase is in place
  • Estimated price range for audit: 5k-15k USD
• Pilot a small test pool on mainnet
  • invite a few known UMA holders to test the system (~10 deposits and ~5 withdrawals)
  • trial period: ~3 month
• Executing marketing, collateral and campaigns including social media

Structure of funding request (KPIs)

Phase one:

50% of funding request upon confirmation of funding proposal and request by parties:

12,000 USD

• Development of Proxy Voting contract and factory
• Unit and integration testing of new contracts
• Build a user UI
• Pilot a small test pool on testnet

Then 50 % of funding request upon satisfactory completion of phase one work:

12,000 USD

Phase two:

100% of funding:

5,000 -15,000 USD (estimate)**

• QA and/or audit of new contracts

• for more details see breakdown above under: “Total Budget Requested”

**dependent on whether UMA can facilitate OpenZeppelin audit hours from their pre-booked contingent.

Outlook/future work

Completion of phases one and two will result in the delivery of a functional, stand alone technology product. A possible further budget request will thematically address further aspects as outlined below, the precise specifications dependent on the outcome of the prototype and community feedback.

Phase three

• General access rollout for additional delegates to launch proxy voting via factory
• Set up a dashboard (possibly on https://vote.uma.xyz or other platform) where UMA holders can go and delegate their UMA to their delegator of choice (and switch delegates or unstake if desired)
• Subgraph for indexing delegation data and delegate historical activity
• Integrate snapshot for offchain delegator signaling for votes
• Integrate oSnap for onchain execution of snapshot votes
• Expand factory system for seamless deployment of proxy voter contract + oSnap

Do you support moving this poll forward?

• Yes
• No

[pemulis1]

I’m glad that you’re trying to find a way to increase UMA token staking and lower the costs for Risk Labs to do gas reimbursement. I do have a few concerns about the proposal as-is:

1. Delegation would tend to decrease the number of active voters, since delegators do not have to review evidence or submit votes themselves. This could decrease the quality of dispute resolution since small voters may not earn as much in rewards but could make important contributions to the discussion.

2. The delegates do not have the same skin in the game as the delegators, which could decrease the economic security of the DVM. Imagine that delegates have 30% of the voting power but only personally lose 1% of the value destroyed by a corrupted oracle. That reduces the cost of a bribe attack.

3. Since delegates as a category have less skin in the game, and will only lose future delegate fees in the case of a failed attack, they may be willing to take greater risks. The value of their future delegate fees may be a small fraction of the potential rewards of a large attack. Even a large attack that is unlikely to succeed, say 5% chance, may be economically rational if all you’re losing is future rewards. This is also a big problem with Chainlink.

I would be more interested in a system that allowed cheaper L2 voting or offchain voting with onchain settlement through oSnap. Let’s say you have L2 of offchain voting, and the DVM can not give a final settlement until those votes are considered. You could pass those vote results in optimistically with a very large bond to ensure correctness, or maybe a zk-proof of the vote results. The votes could be submitted to the DVM during the commit period to ensure settlement on the same timeline that protocols are currently used to.

This would obviously require revising the DVM itself, so not an easy task. But it would be a more comprehensive solution to the gas cost problem, and something that all voters could safely use without threatening the oracle’s cryptoeconomic security.

[SlowChimera]

I’m not sure that I agree with you @pemulis1 that L2 or offchain voting is the way to go rather than delegation. L2s can and have gone down; they haven’t been stress tested in a bull run and they add an additional attack vector. And I may be misunderstanding the mechanics here, but using oSnap where the voting is off-chain seems to be introducing a circular vulnerability.

I do think delegation is the way forward, particularly as its been muted that at some point in the future protocols using UMA for resolution may require to prove skin in the game by holding UMA (and thereby having the right to vote), and I think having a delegated solution is means by which this could be implemented.

That said I do have reservations about this proposal.

• the SuperUMAns appear quite opaque. The channel they had in the UMA discord server has disappeared, and I’ve asked a couple of times how to join, but never had a clear answer beyond joining their discord, but all of their channels seem locked down.
• there is no clarity over the SuperUMAn multisig - as its the controller of the proxy voting contract, I’m a bit concerned about security.
• Delegate signalling in determining votes is included in Phase 3 (subject to a future funding proposal), however this proposal as it stands relies on delegates trusting an unknown vote determination process.
• This coupled with the unknowns surrounding the multisig, makes me wary of the potential of bribery, particularly on Polymarket where votes can be contentious and there are known bad actors who have previously attempted nefarious means to sway UMA voters in their favour.

Beyond that, I dont have a clear view of the architecture, in particular whether the controller can modify lockup periods and how the unstake element interacts with slashing and rewards during the cool down period.

I think this proposal has a lot of potential, but needs more clarity over the architecture of the proxy contract and its locus of control.

[neondaemon]

Thank you for the considered comments, all very reasonable points and ones we have much discussed during the extended period of setting up this proposal.

1. “Delegation would tend to decrease the number of active voters” All things being equal this would be the case. However, there are around 140 stakers (last time I looked) and only 70 to 80 are actively voting. This first pool is aimed at small token holders, up to 1000 or maybe 1500 UMA. Other delegates may come in and change this as it will be configurable. This is the group that are most likely not voting, I know a few of them personally including one that has decided to unstake and sell up.

2. The delegates do not have the same skin in the game as the delegators To mitigate this we are considering setting up a min amount that delegators have to stake themselves

3. Since delegates as a category have less skin in the game … they may be willing to take greater risks Initially the SuperUMAns will manage this and I think we have proven to be good UMA citizens. In time other delegates will come in and compete for stakers, this will keep fees low and delegates will have to perform well (vote consistently and correctly) to keep their stakers and attract new ones.

4. I would be more interested in a system that allowed cheaper L2 voting or offchain voting Me too! I think with the advance of zk rollups we may be able to vote on a L2 and it be reflected on mainnet. I did ask this question some months ago and was told it was in the ideas stage. If you know of any developments in that area would be very interested to know.
   As for oSnap if all goes well, this is something we have put on the roadmap to give stakers some way to indicate which way they would like to vote.

[neondaemon]

Hello, Thanks for the comments, just want to try and allay any fears you may have:

the SuperUMAns appear quite opaque sorry if this is the case. It’s not intentional. The channel in the UMA discord has gone as part of the reorganisation that was undertaken. We are not actively recruiting right now. Having said that, we have a general call every Monday at 2pm utc and you can come and introduce yourself and take part.

there is no clarity over the SuperUMAn multisig I am part of the SuperUMAn multi-sig. We will create a new safe and multi-sig. We will not be the controller of the proxy voting contract. Other delegates will be free to come in and use it, we will just be the first one.

Delegate signalling in determining votes …relies on delegates trusting an unknown vote determination process Initially, it will rely/trust the SuperUMAns

This coupled with the unknowns surrounding the multisig, makes me wary of the potential of bribery… If this becomes successful we could have maybe 100,000 UMA to vote with (stakers limited to stake up to 1000 or 1500 per wallet). There are many stakers out there with much greater amount of UMA.

Beyond that, I dont have a clear view of the architecture, in particular whether the controller can modify lockup periods and how the unstake element interacts with slashing and rewards during the cool down period. This is detailed above. Take a look at the diagram as a starting point. For detailed questions @devin will be happy to answer any queries.

Thank you for the time and thought you have put into your comments, highly appreciate it