Proposal: GovFactor

[0xLucas]

Authors: @0xLucas @Coopahtroopa @James @Callum

Summary

Introduce GovFactor, an on-chain voting incentive for Balancer Liquidity Providers.

Background

_ (FireEyesDAO) has been actively working with the Balancer team over the past few months in an effort to develop a robust suite of governance mechanisms to complement the upcoming launch of Balancer V2.

One of the issues we concluded on: consistent voter participation has historically been an issue for many DeFi protocols. Whether it results in proposals not reaching quorum or only having a small number of participants involved, it’s become obvious that protocols must have meaningful voter participation across a diverse group of users.

The GovFactor proposal aims to create a simple incentive mechanism to actively participate in governance for users who already participate in the protocol.

Motivation

As it stands, Balancer liquidity mining incentivizes passive participation. Liquidity Providers (LPs) simply deposit capital and earn BAL. Despite the significant subsidy LPs receive from the protocol, there’s no expectation or requirement that they actively participate in governance.

This ultimately represents a misalignment as LPs have no incentive to vote despite constantly accruing voting weight. If the suppliers are subsidized by the protocol with governance power, it’s important to ensure they also become active stewards of the protocol.

This does not mean that LPs MUST participate, but instead they should have an incentive to participate. Therefore, it may be worthwhile to incentivize those that service the protocol to help govern it as well, aligning their participation with added BAL from liquidity mining.

Specification

The GovFactor is an on-chain voting incentive for LPs that affects BAL liquidity mining allocations depending on whether or not an address voted on the last governance proposal.

A simple implementation for this factor is an “on/off” switch where LPs that voted on the most recent proposal by signing a transaction turn “on” the factor, moderately boosting their BAL liquidity rewards by a GovFactor determined via governance.

Providers that did not vote on the last proposal by signing a transaction have their GovFactor “off”, forfeiting the factor and in turn, receive lower LP rewards than those that voted on the last proposal. This dynamic will remain “off” until the next on-chain proposal is open for voting and ratified on-chain.

If all LPs vote, then the rewards remain the same as if no one votes.

The GovFactor’s “on/off” design creates a simple incentive for LPs to always be active in governance. While the exact numbers are to be discussed, a GovFactor = 1.1 - 1.25 should provide a fair boost to an LP’s BAL liquidity incentive in return for completing their basic duties as a steward of the protocol. To make calculations as simple as possible, GovFactor would be applied after all other factors.

GovFactor looks at addresses who have voted on the most recent proposal featured on Snapshot and references to see if the address is also providing liquidity to the protocol. If both variables are met, the protocol includes a factor to their weekly BAL liquidity mining allocation.

Regarding community concerns about doxxing, it’s important to note that this reference happens entirely on-chain, meaning there’s no need to cross-link any addresses to a forum or public username.

Ultimately, the GovFactor creates a unified incentive for those that service the protocol to become active governance participants as well and should be considered by the community as a simple mechanism for encouraging governance participation from the protocol’s service providers.

Drawbacks

Some points to consider surrounding the GovFactor:

• The end result could be a lot of non-engaged voting, coming from LPs who don’t hold meaningful amounts of BAL (even if being large LPs) and who don’t really care about Balancer governance, putting little to no effort in the decision process behind their votes.
• The GovFactor encourages LPs to vote through their liquidity mining address, which could pose some issues for opsec conscious users. However, Snapshot now enables delegation from cold wallets which would mitigate this issue.
• The cadence between different governance proposals is likely to differ. This means that someone who votes on the last proposal preceding a large time gap to the next proposal may see increased liquidity rewards despite not actively participating in governance discussions.
• The state of Balancer Governance is relatively idle and therefore implementing a governance incentive isn’t currently necessary for the success of the protocol.

Vote

Poll 1: Consensus check on implementing a GovFactor as described above

Implementing GovFactor

• For: Implement a GovFactor for Liquidity Providers
• Against: Do not implement GovFactor and keep LM factors as it currently stands

Poll 2: Consensus check on GovFactor “on” weighting

GovFactor Weighting

• 1.1
• 1.2
• 1.25
• 1.3

[Coopahtroopa]

1.25x feels like a good multiplier to me. It will be interesting to see how this pans out as more proposals are brought to the table and more specifics around the decay around a multiplier should there not be any new proposals for extended periods of time.

Overall I am in favor of this proposal!

[DavisRamsey]

this essentially just further increases the incentive to provide BAL liquidity? Unless I’m missing something, since only LP’s with BAL can vote.

But I guess any LP can just get 1 BAL in their wallet to vote then sell it immediately after, until the next vote.

If that is accurate, then I support this.

[tongnk]

Might want to have some modelling similar to last time to show the actual impact a LP vote is going to be.
It’s going to be hard to give a thought without just pulling a number out of thin air right now - the APY calculations are complex enough that us normal humans can’t understand what impact a 1.1 vs 1.3 makes

Another point I still have issue with is the fact there is no success metric. What does success look like? I would be tentatively for this - but we need to work out how to track success and how to track if it’s actually providing value or if it is simply donkey voting

[zumzum]

I am against any further inflation and BAL distribution. Moreover, balancer has already a solid team that is working within the DeFi space to better integrate the platform, improve UI etc.
The only reason why LPs and token holders are not engaged is simply that voting proposals need to be actively found in the snapshot page or when you are lucky enough to bump on some proposal on discord (like today) > very inconvenient. This mechanism therefore is overlooked by 90% of us. Voting proposals should just be integrated within the Balancer app in an easy-to-find way.

[0xLucas]

There’s no further inflation on BAL. The GovFactor readjusts how the existing distribution works and gives a higher weight to those who are active governance participants.

Agreed that there may need to be a better user flow so people have a better engagement/understanding on the state of Balancer governance. With that said, there’s not much to govern right now as all the V1 contracts are immutable. But, we’re assuming that will change with the launch of V2 and the protocol becomes more complex.

[0xLucas]

Voter participation could be one KPI (i.e. aiming to have x% of all BAL voted on every proposal)

Another one could be overall governance engagement and participation across the forums, discord, and on-chain proposals. This one is a bit more abstract but this is really the broader goal for _ and our past discussions.

[Fernando]

Agreed with @tongnk: I think the % increase in votes (both in number of BAL and also unique wallets voting) is going to be a simple and good success metric. I would bet these numbers are going to increase many fold if this proposal is accepted: LPs will have an incentive to vote (and hopefully get informed/participate more in the community discussions) which they don’t ATM.

Like @DavisRamsey says, any LP could buy 1 BAL to vote then sell it just to increase (or avoid decreasing) their share of the weekly BAL distribution, but if everyone votes and does that then nothing is going to change: if everyone gets a govFactor, then it means everyone gets the same as the number of tokens will still be normalized at 145k.

[DavisRamsey]

some LP’s will definitely not vote. might forget, not know about it, or not be able to vote in the case of staking their BPT in a 3rd party contract.

for example, the BPT from Aave’s forthcoming 80/20 pool would be staked in their governance contract. if their governance contract doesn’t vote, none of that liquidity gets govFactor.

[Coopahtroopa]

After further discussion here it looks like 1.1x as the multiplier here makes more sense. Taking the community sentiment into account we’d love to introduce GovFactor as a trial and use voter participation as the key success metric here leading up Balancer V2.

Given there are no strong oppositions, we’re planning to post this to Snapshot for a formal vote in the coming days. Thanks for all the great feedback and we’re looking forward to seeing if the BAL voter sentiment matches the internal and community support!

[almccann]

I am fundamentally against the notion that as an LP I should be coerced to participate in voting to receive a better return on capital in the form of BAL rewards.

I want to LP to balancer because it’s an index fund and I want a way to passively invest with less participation, not more. I want to opt-out and know the return is consistent, not altered afterwards because I did or did not do something. Who has the time?

To me BAL will be valuable when it offers an income in the form of exit fees, not due to governance participation.

In the very least there needs to a way to delegate and not be penalised.

This approach reminds me of the insurance companies that reward exercise as measured by the phone step counter, and people just stick their phone on an electrical stepping device.

[0xLucas]

As mentioned above, we’ll be moving forward with the govFactor = 1.1 and a 3 month trial to test out the incentives with the upcoming Balancer V2 roll out.

Polling ends on December 21st!

You can vote here:

Snapshot

[Coopahtroopa]

Hey @almccann wanted to address your concerns.

@almccann

coerced to participate in voting

I’m very sorry to hear you think this is negative ask of LPs. Seeing as you are earning a governance token, I believe it is your social duty to participate in governance or at the very least be rewarded for doing so.

@almccann

Who has the time?

All of us on this forum have the time. All of the protocol politicians who see governance as the single most important aspect of web3 have the time. We have intentionally made the govFactor proposal very minimal (it’s only a 1.1x multiplier) as to ensure those who do not vote do not see major changes from the BAL they are receiving today. This proposal is one step in a wider strategy to reward the protocol’s most active and value-added actors as illustrated in the Governance Mining proposal.

@almccann

there needs to a way to delegate

This is a very valid request and something others have voice too. We’ll definitely explore this leading into the new year and agree it would be a valuable tool to offer for those who might not have as much time or passion about governance.

Overall, your concerns are definitely heard and I’d ask that you please watch your tone in future conversations. We’re all on the same team here and have a common goal of advancing the Balancer ecosystem. If you are strongly opposed to this proposal you are welcome to vote against it on Snapshot but I hope these comments can help you better understand where we’re coming from. Cheers!

[Coopahtroopa]

@DavisRamsey my bad realized I forgot to respond to this!

I’ve also been thinking more about how BAL staked into pools or BPTs in third party contracts would be affected here.

To emphasize my last comments, I really think making the govFactor a minimal enough shift (1.1x) as to not drastically alter these actor’s rewards feels like a good middle ground.

We’ve presented this as a three month trial, and believe we should have sufficient data to back this up should it get passed and implemented to address edge cases and concerns!

[DeptOfLabor]

I think this is going to be good.

I initially voted against it based on the drawbacks outlined above.

I then reconsidered and voted for it as I think its valuable to be open to change. We could talk for days about what ifs that never happen. Its not a bad thing even if a revert is desired after a time. It would just be a thing.

[KW710]

Deleting my post as I realized that I had gotten it wrong. Carry on

[almccann]

The best strategy for engagement is to create a wealth effect for community members.

If true wealth is created via economic value accrual to BAL in the form of protocol fee income, an engaged community will form.

Another analogy: this is paying developers for lines of code instead of for solving a problem. You may get a few donkey votes but will you get a community?

Focus on wealth effects, protocol fees for BAL, LP value proposition and people will show up.