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
I love these ideas. I can check to see if those are available options.
Hey @kyle, thanks for getting this conversation started, and thanks for your patience in my reply! Has been a busy few weeks for us 
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 
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!
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?
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
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?
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:
Thanks, Ben.
As an FYI on progress for others. We have been making progress on adopting this and will likely move to change out the contracts after Eth Denver. we are delaying our roll out a bit as we want to make sure Tally.xyz can support the new contract details too.
You can see the repo here: GitHub - gitcoinco/Alpha-Governor-Upgrade
Yes! Thanks Kyle. A couple other notes that folks might be interested in:
Thanks to the community members who came to my Schelling Point talk. Iāll post the video once itās available as well.
After the talk, I had a great brainstorm with a few folks about even more cool stuff that can be built with Flexible Voting. People keep coming up with cool new things that could be built, including:
There was a lot of interest for Flexible Voting at ETHDenver from other DAOs as well. Our audit with OpenZeppelin starts this week, and Iāll share updates on that as it progresses. Thereās a lot of momentum building for more modular governance! Weāre excited to get the proposal up for the Gitcoin community later this month!
Hey Ben,
After your presentation, I spoke with several other governance architects about the capability and there was broader interest beyond Gitcoin. Specifically @mmurthy at https://www.karmahq.xyz/, the folks at the DAO Governance Collective and mel.eth who has some interesting delegation ideas where this could be put to work. Ping me in discord and letās continue the conversation shawn16400#5507
Amazing! Thanks so much. Friend request sent on Discord.
Hey all - one more update!
We are getting close to our deploy and testing phase. This means, contracts have been audited, settings have been set (currently no planned changes to the governor options), and we are getting ready to start our testing. We will deploy the new contracts and expose those so that we encourage additional testing 
Stay tuned for more details next week!
Hey everyone, as @kyle said, weāve completed the audit of Flexible Voting Governor with OpenZeppelin, and the results are now available for public review. Only a few low severity issues were identified and all have been fixed.
Later this week, weāll be deploying the prospective new Governor for Gitcoin and sharing the upgrade proposal with the community to begin the formal governance proposal.
You can read about the audit and everything else going on with Flexible Voting (thereās a bunch!) in this Twitter thread we just shared: