Transition to Snapshot voting for Rewarded Pools

I would like to propose that we transition from on-chain voting to SnapShot based voting when it comes to updating/adding/removing rewarded pools. The current process is too slow and limiting to be effective.

Current Issues with On-Chain Voting for PNG rewards

  • High barrier to entry: requirement of 1M PNG to submit a proposal
  • Cannot vote with PGL: voters need PNG in their wallets to vote, but many users are staked with PGL
  • Long end-to-end process: It takes 11 total days (1 day waiting period + 3 days voting + 7 days execution delay) to get a new pair rewarded in Pangolin
  • Technical limitation of adding 4 pairs: Since on-chain proposals can only submit a single transaction, there is a technical limitation due to maximum gas that can be spent in a single block. This allows only 4 pairs to be added at a time.
  • Gas cost: voters need to pay a gas fee to vote

Proposed Improvement - move voting for new pairs and pool updates to SnapShot voting

  • Reduced PNG minimum requirement to submit a snapshot. We will start at a 10k minimum.
  • Users can vote with both PNG and PGL
  • Reduced end-to-end duration, we can reduce the 1 day waiting period and 7 day execution delay so we can implement new pairs more quickly
  • No technical limitations - we will not be bound by the 4 pair limitation that we saw with on-chain voting
  • No gas cost: voting is free!

Technical implementation

  1. Set up a new snapshot system that uses both PNG, LPs (PGL) and Staked PGL - Bmino is working on this already
  2. Set a 10k PNG minimum to submit a snapshot proposal, and a 1M PNG quorum threshold for a proposal to pass
  3. Submit an on-chain proposal to change the owner of the LiquidityPoolManagerV2 contract from the GovernorAlpha contract to the Pangolin Multisig. The multisig will be responsible for adding/removing/updating pools when snapshot proposals pass with quorum.

Additional Info

  • Other governance functions (moving treasury funds, changing contract ownership, etc.) will still need to go through on-chain voting. This update is scoped specifically to adding/updating/removing rewarded pairs.
  • We can adjust the 10k PNG minimum and 1M PNG quorum numbers as needed if we realize these thresholds are too low or too high

Moving to a more agile SnapShot voting system for PNG rewards will streamline the process of adjusting pool rewards to best reflect the needs of the community and ecosystem.


If making changes, why not just create a separate on-chain governance contract that handles the above vs an off-chain snapshot.

1 Like

Our original idea was a governance proxy contract that can get around the 4 pair/10 transaction limit.

This introduces some smart contract risk and would require thorough testing and review.

Without changing out the governance contract entirely (would require dev time, testing time, potentially an audit), a governance proxy contract still doesn’t solve the problem of a 1M PNG minimum to propose on-chain.This has proven extremely difficult for projects to accumulate since most PNG is staked and LP’d.

So after discussing, we decided SnapShot is the most flexible for the projects needs.


Also the 1M minimum is hard coded into the current governance contract so we cannot just change it as a parameter, it would need to be a new contract.

I’m open to pursue a separate Governance system responsible for changing rewarded pools and weights. This could have a lower proposing threshold and definitely a shorter turnaround since it is only responsible for making changes that wouldn’t require lead time to inspect. However, it would still be limited to 4 pairs which is imposed by Avalanche’s block gas limit.

The thought process here is to use some snapshot functionality that will allow us to use PNG in many locations (ie staked, held, pending rewards) and perhaps move into a model where all voting can be gas-less via snapshot and is guaranteed to be executed via a gnosis safe via their plugin. This functionality doesn’t exist on Avalanche yet, but could be ported in the near future.

I really want voters to feel more engaged with Pangolin and voting with more PNG available and in a totally gas-free setting seems to be a nice step. Thoughts?


I remember reading about the Gnosis Safe plugin for Snapshot, Safe Snap. I remember initially overlooking it a bit because of the reliance on oracles. However, I didn’t give the oracle system they mentioned a suitable dive. So I will take some time to do so…

1 Like

For anyone wondering, here is the current snapshot voting page Snapshot

And here is the on-chain voting page

1 Like

One of the things that impressed me most about Pangolin is the robustness of the decentralized architecture.

Given a potential reduction in threshold and the current assets of the Dev Treasury, it would seem an On-chain governance mechanism with the limitation of the 4 pairs at a time, it would still be viable to maintain the rewards allocation on-chain.

Also, at some level, the limitation of 4 pairs at a time does provide an additional levels of granularity. However, depending on the roadmap, this could be too high of friction if batches of new pairs are added frequently (daily or weekly). But if this is the case, this would seem to be a reason for implementing a different allocation structure for pairs and adding them vs snapshot voting.

Also, off-chain Snapshot voting seems to further increase the fluidity of governance decisions to short-term stakeholders being able to move in and out at leisure (unless there is a post initial snapshot functionality in voting to check balance at end and beginning).

I am reticient to move the capabilities of standalone avalanche functionality to additional dependencies.