Request for feedback: UMA-GYSR Delegator Pool Proposal

Name of Project: UMA-GYSR Delegator Pool

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


UMA’s Voter dApp 2 ( 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.


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


  • 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


  • 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 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

I really like this proposal!

A few light notes to start (will add more as I think about it more).

Risk Labs already has an agreement with OpenZeppelin with pre-allocated audit time. Rather than paying for a standalone audit out-of-pocket, it could make sense for Risk Labs to donate some of the preallocated time for this contract suite. Might be worth doing some shopping around to see what an external audit would cost for comparison.

I started a draft of a delegation contract (personally) a few months ago here: It’s in a very incomplete state, so I would want to clean it up and make it functional before collaborating on it, but if I worked with y’all and we used that draft as a jumping-off point, it might reduce the time needed for contract development. In general, I would love to collaborate with y’all on this.

Lastly, what is Passage? Is it a 3rd party development contractor?

1 Like

Interesting proposal and worth full consideration to maximise voting participation and encourage other holders to stake their UMA.

A couple of points

  1. The mention of gas fees omitted to mention the gas-fee rebate scheme by RiskLabs, market conditions may mean that small users still lose, however the change from payment in UMA to payment in Eth, means that there is no exchange risk/costs now, which should help small voters, (of course there is no guarantee that Risk Labs will continue to offer this rebate.)

  2. In the diagram, the shown delegate is the SuperUMAn Multisig and it seems that support for other delegates is in phase 2. Given that this delegate will have first mover advantage, clarification around the control of the multisig/governance/vote determination mechanism would be useful.

  3. The development costs seem reasonable, however the issue of delegation has been discussed a number of times on the UMA Discord and there are a number of tricky issues around unstaking, vote decision making and the commit/reveal cycle. It would be good to see how these issues are addressed, especially as the development is outsourced to Passage. I also wasn’t very clear about the flow of UMA around the system, where users sent their UMA (to the delegate address?) where it goes then (to the GYSR pool?), and where the accrued UMA rewards from staking went (to the GYSR pool for distribution?) or if delegates only received their rewards once fully unstaked.

Hi SlowChimera, thanks for the comments,

  1. Yes gas rebates in Eth is a very welcome change. There is still the issue whereby you need the Eth upfront to be able to vote. When gas is high and there are many votes you might run out. I can talk out of personal experience on this score. There is also the opportunity cost, i.e. what else I could be doing with that Eth.

  2. Initially, the SuperUMAns will manage the vote, we are already doing it for our DAO. The initial idea was that the staker would just delegate without having a say, we will explore various mechanisms to let them weigh in if they want to. The Delegator will be able to configure, commission, max no. uma etc. The idea, if it becomes popular, other delegators will come and compete just as validators in other systems do now.

  3. GYSR merged with Passage (At the time of writing this Devin’s response to mrice32 is still being held by the system. We have been working with Devin for a few weeks now to come up with the current proposal. As GYSR’s staking pool was already audited we thought that holders could stake in uma pool and then the uma from the contract would be put into the voterDapp. Unfortunately that’s not possible. This why we have a Proxy Voting Router that will sit between the GYSR pool and the voterDapp. Holders will stake in the GYSR pool and receive rewards, no need to vote and no slashing!

Thanks again for the questions, if you have any follow up ones will be happy to discuss.

I would like to have a more free-flowing chat on this proposal so I’ve started a thread in Discord on the topic, and tagged the authors: Discord

1 Like

Hey @mrice32 thanks for the response!

The idea of using an existing time allocation with OpenZeppelin for audit sounds interesting, would love to explore that option.

Awesome to hear you’ve been thinking about and prototyping a similar concept. Would love to dive in together to discuss implementation details and possible reuse of that draft smart contract.

And for context, Passage and GYSR are sister protocols – Passage Labs provides core team, incentive design strategy, and solutions implementation for both product systems

I did assume that the SuperUMAns would manage the vote, I was just wondering about how that was done, particularly if it may affect rewards/reward rate from the GSYR pool.

Perhaps this is better aimed at @devin , but I was wondering about the mechanism and the flow of UMA around the system.

The way I’m assuming it works is…

  1. User deposits UMA to GYSR staking pool with a fixed APY
  2. Proxy voter contract uses the UMA in the staking pool to vote
  3. Rewards accrue in the staking pool via the proxy voter contract (is claiming part of that contract or manual?)
  4. On withdrawal from the GYSR pool, user receives stake + GYSR APY.

Is that correct?

1 Like

Hey @SlowChimera – you’re right on, just a couple of small clarifications.

  • the earning rate from the GYSR pool will be variable and depend on ongoing earnings streamed from the voting contract
  • the proxy voter contract deposits staked UMA into the normal voting contract, then assigns rates per user to keep track of balances and also to distribute rewards proportionally
  • the pool controller (and delegate) can either choose to distribute or compound rewards for the pool globally. Distributed rewards can either be compounded or claimed by each user (lots of flexibility!)
  • and exactly, an unstake will transfer original position + interest (or minus penalty) + rewards to the user
1 Like

This proposal has been modified in line with the feedback from the AMA with stakeholders. In particular, funding has now been split into separate parts, 50% at the start of the project and once specified milestones have been accomplished the other 50% will be released. The audit is kept separate. It may be possible to use some of UMA’s time allocated with OpenZepplin if not we will seek quotes from a number of auditors to get the best price possible.

Have moved this proposal over to the funding section: