Name of Project: UMA-GYSR Delegator Pool
Proposers:
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.
Part A: Description of issue
Background:
UMA’s Voter dApp 2 (https://vote.uma.xyz) introduced a two step model:
- staking rewards irrespective of engaging in any voting activity, and
- 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
- Proxy should be subject to increased magnitude of both rewards and slashing
Total Budget Requested
The total budget calculated and requested by the SuperUMAn + Passage team for phase one and two:
24,000,00 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,00 USD
- Unit and integration testing of new contracts: 5,000,00 USD
- Estimated price range for audit: 5k-15k USD
- Project preparation, management, testing, user UI, marketing: 9,000,00 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.00 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.00 USD
Phase two:
100% of funding:
5,000.00-15,000.00 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