[feedback] Upgrading the Gitcoin Governor Contracts - Flexible Voting?

Hey Everyone - I have some excited news to share, and I would love to solicit feedback before we get too far along on a few of our Governor upgrade details.

After a couple of false starts, we are about 2/3rds of the way done in scoping the new Governor Contracts for the Gitcoin DAO and Treasury. These contracts are being developed by our friends and partners at ScopeLift. These folks have worked with Gitcoin for years and have helped us build a number of other products. They have also been championing flexible voting for DAOS and worked with Uniswap to introduce this concept.

Okay, so the exciting news! We are about 2/3rds of the way done and we have a few questions we would love community feedback on. If you can answer the poll, it would be greatly appreciated, but we are essentially looking for feedback on if Flexible Voting should be implemented as part of this governor upgrade, or if we would like to “play it safe” and avoid allowing the voting mechanism. From @bendi - “Flexible Voting allows for the construction of new mechanisms which make governance participation easier, cheaper, and more accessible for GTC holders.”

You should really checkout the post linked above what flexible voting is, but to save a few clicks, here is a great graphic outlining the benefits of it. Essentially flexible voting enables Snapshot strategies. Those who have GTC staked in an LP can still use that GTC to vote for on-chain proposals.

We are about to start testing the new contracts and will have more info to share on those soon, but we hope to have a vote live in January to upgrade the governor contracts from the Governor Alpha we have today, to an Open Zepplin Variant of Governor Bravo. I can share more of the contract details in a subsequent post soon (ie, if threshold amounts changes are proposed, quorum numbers, etc.)

For now, give me your thoughts on flexible voting!

  • Yes - Flexible Voting is important to our Governance
  • No - Flexible Voting doesn’t seem necessary and we should skip it.

0 voters

5 Likes

Just catching up on this concept and it looks appealing. @bendi if you need help in scenario development or testing, let me know - I would be happy to help!

2 Likes

An open tab that I missed here - I voted no here because we mainly use Tally for transferring funds, not so much for voting itself, so not sure it is needed.

I appreciate the reply and the consideration.

I was of the same mindset as you Kris, but then I wondered if having that option would still be important for those who dont want to hold GTC in a wallet. ie, large token holders could move tokens to Aave and then still help us ratify snapshot results.

I like that it gives folks more options on how to hold their GTC.

Not sure if I understand it correctly, but I believe the delegation happens on Tally for both Tally and snapshot. Therefore, the upgrade to flexible voting would make it easier for us use tokens for governance while also using them for other productive use cases.

I would also like to propose that we should add some type of either

  1. Expiration of delegations
  2. Ability for someone to drop their delegations if they no longer want to participate

I love these ideas. I can check to see if those are available options.

@bendi to perhaps chime in… and @mds1

1 Like

Hey @kyle, thanks for getting this conversation started, and thanks for your patience in my reply! Has been a busy few weeks for us :sweat_smile:

You did a great job summing up what Flexible Voting is all about. We think being able to participate in both DeFi (with your GTC) and governance at the same time is a compelling use case and we recently received a grant from Aave Grants DAO to add Flexible Voting support to ATokens. We expect the work will be done early next year.

One note I want to add: while depositing tokens in DeFi protocols is one of the use cases we imagine, there are a lot more, and some of them are just as exciting—if not more so. A couple I’m really excited about are Layer 2 voting (bridge your GTC to a rollup, vote from the rollup with low gas fees) and shielded voting (deposit your GTC to a pool and vote privately with ZKPs).

Sure let’s chat. Will follow up!

Hey @krrisis, thanks for your thoughts! I’m not quite sure what you mean here regarding Tally and transferring funds. Happy to expand if you have any specific questions. That said, we’ve been in touch with the folks at Tally (they rock!) and they’ve signaled their support for the FV mechanism, and even a willingness to support it in their tooling should a DAO request it!

Yep! That’s exactly right @DisruptionJoe

This is an interesting idea! Since delegations happen inside the GTC contract, not the Governor contract, the only way to add this by default would be to migrate the community to a new version of GTC. That said, with Flexible Voting, you could design a delegate contract that sub-delegated to regular voters, and included configurable expiration by default. In other words, with Flexible Voting you could build an opt-in version of this.

As it stands now anyone can revoke a delegation by re-assigning it at anytime, including to themselves or to no one. So I think this basically exists already. Unless I’m misunderstanding what you mean?

Anyway if anyone else has other questions about either the Governor upgrade or Flexible Voting, please hit me up! I’ll be keeping an eye out for replies :slight_smile:

As a steward who is receiving delegations, I no longer wish to participate in this ecosystem and would like to release all delegations that are currently assigned to me.

Ohh interesting I see what you mean now—the steward removing other delegations. I’m curious about the motivation for this feature. Like a ragequit kind of thing?

Thinking about the implementation, similar to the idea of expiring delegates, I believe to implement this globally you’d have to migrate the community to a new version of GTC. But I believe, off the top of my head without thinking about it too deeply, it could also be built as an opt-in feature with Flexible Voting. Great example of how this new primitive will allow the building of all kinds of new stuff by 3rd party devs, including things we haven’t conceived of yet!

Edit: Grammar

This request came from a specific incident. One steward of ours who was also a steward from ENS was offered a full time position with Gitcoin. They posted on ENS about the offer and that they no longer could put the time and attention to being a good steward, but not many read it.

A while later they were confronted at a conference from an ENS fan/user who was upset that stewards with large delegations, this person specifically, were not paying attention.

This steward had no ability to say “My priorities have changed and I can no longer serve in this role”

Yeah this makes sense. Like I said, a great example of how FV can be used to build lots of stuff. In the future I can imagine that the large majority of base delegations will be to contracts that come with their own sets of rules and features like this. It allows innovation in the way delegation works without having to ever upgrade the token contract!

1 Like

I like this concept as it stands. I think it adds a lot of, well, flexibility. I think a more balanced decision could be made on whether or not we should upgrade though if we got a full understanding of the risks of updating. How battle-tested is the flexible voting contract? What new attack vectors do we open ourselves up to? How much more context does this require of the average voter (i.e., does this add a lot of complexity that would require some of our non-technical voters to read up on?).

Also, another separate question that I’m curious about, does this allow me to give GTC to someone while keeping the voting power without their knowledge? As in, could I give my GTC to person A, but beforehand delegate the votes to contract B without person A’s knowledge?

2 Likes

Hey @chaselb, these are all great questions! Let me try to take them one or two at a time!

Flexible Voting is an extension of the battle tested OpenZeppelin Governor. The OZ Governor is audited and used by many DAOs. Our extension is minimal and can be be seen here. A good chunk of the code in that contract is itself borrowed from other OZ extensions. Overall the “new code” is extremely minimal, which is by design! All that said, we are also pursuing an audit for the extension, with funding being the biggest blocker.

The short answer is none. If a holder or voter is happy with the way things currently work, then no change would be required in their behavior. The FV system is fully backwards compatible with the existing Governor and so voting and delegating can continue as-is. Where a user might need to think a bit is if they choose to opt-in to something built with FV that enables a new experience.

For example, we’re currently finishing up AToken support for FV with a grant from Aave. This would theoretically allow depositing your GTC into Aave, but still voting with your share of the unborrowed Pool. Obviously, a new UX will have to be built for this, and obviously we’ll want to keep that UX as clean and simple as possible. But all of that is purely on an opt-in basis.

Nope! Delegation is done in the GTC Token contract, which would change, so the rules around delegation don’t change either. When you transfer your GTC, your delegation (whether to an EOA or to a contract) is reset.

Edit: clarity

2 Likes

Okay so just to be clear, the proposed extension is currently unaudited, and not currently implemented by any other major DAOs?

Also, this leads me to a belief that in order for users to get benefits from the type of examples listed above for FV, the actual lending protocols would have to add some sort of functionality on their end. Is this correct?

1 Like

Yep, the new code is not yet audited (working on it) and not yet used by a major DAO.

Correct. In the case of Aave, they’d have to deploy an FV compatible AToken for GTC, or any other Governance token. They’ve given us a grant to write said AToken contract, which should be done soon.

In general, we’re very aware that the project has a bootstrapping problem, i.e. a chicken-and-the-egg style issue. We’re aggressively attacking this from every angle, as we discussed in the blog post, to try to get the activation energy needed.

We believe the adoption of FV will be a big unlock for the ecosystem, and in the spirit of Public Goods we’re trying to make it happen with grant funding and community support! We’ve had a number of parties express support for the extension, and should have some more announcements to share in this regard soon.

Gitcoin has often been a leader in adopting new tech in the ecosystem. ScopeLift helped build the zkSync integration into Gitcoin Grants back when zkSync was the only rollup live in production, and had less than $100K in funds on the network. I think it’s fair to say that decision by Gitcoin was an inflection point for Ethereum’s L2 ecosystem. We hope the Gitcoin community will see this as an opportunity to once again be leaders the ecosystem.

For anyone interested, we just shared a blog post about our integration of Flexible Voting with Aave, which is now completed:

https://twitter.com/ScopeLift/status/1621275019929059329

1 Like