Introducing Flexible Voting: A Powerful New Building Block for DAO Governance
July 14, 2022 / Ben DiFrancesco
This is a long post! If you've only got a minute, here's the quick take on what Flexible Voting is all about:
- Funded by a grant from the Uniswap Grant Program (UGP), ScopeLift has developed a new extension to the widely used Governor system pioneered by Compound and used by many DAOs
- For a DAO that adopts it, the Flexible Voting Governor extension allows delegates to split their voting weight across For/Against/Abstain options for a given proposal
- This new building block allows arbitrary delegate contracts to be developed which can unlock all kinds of new use cases, such as:
- Voting with tokens while earning yield in DeFi
- Voting on L2 with bridged tokens
- Shielded voting (i.e. secret/private voting)
- Cheaper subsidized signature based voting
- ScopeLift is eager to continue expanding the system's capabilities and to see real DAOs adopt it. If you'd like to help us build it, fund it, or get it adopted by a community you're a part of, please get in touch!
In February of this year, ScopeLift received a grant from the Uniswap Grant Program (UGP). The high level goal of our grant was improving the safety, resilience, and accessibility of Uniswap DAO's Governance. Our aim was to do so in a way that would also benefit the broader ecosystem. In this vein, our work was focused on two tasks.
The first task was the improvement of Seatbelt, a tool to perform automated checks on governance proposals. We'll write about Seatbelt in a future post. Today's post focuses on the second half of our work with the UGP: Flexible Voting.
Listen to Ben DiFrancesco and Matt Solomon discuss ScopeLift’s work on Flexible Voting in this excerpt from Uniswap DAO Community Call #27.
When UNI Came to Compound
In October of 2020, the Compound DAO voted to support UNI on Compound Finance. With the addition of UNI to Compound, holders now faced a choice: would they use their UNI to participate in governance (either actively, via on-chain voting, or passively, via delegation), or would they use their holdings to earn yield?
Users are forced to make this choice because the Uniswap DAO's Governor contract, like most in the DAO ecosystem, assigns voting power based on the address that holds the token when a proposal is created. When UNI is deposited in Compound, it is held by Compound's contracts, not by the user who deposited it. The user gets a receipt token called cUNI in exchange. As a result, it's not possible for a user to vote or delegate with UNI they have supplied to Compound.
To mitigate this tradeoff, members of the community proposed a workaround. First, Compound delegated its UNI votes to their community multi-sig. Separately, the community arranged to use the Snapshot tool to set up off-chain, signature based votes on each proposal. The multi-sig signers pledged to vote on behalf of cUNI holders based on the off-chain vote.
While creative, this approach had several problems. Those problems stem from the fact that a delegate's vote is all or nothing. So if cUNI holders are split 51% "Against" and 49% "For" a given proposal, the full weight of UNI in the liquidity pool will nonetheless be used to vote Against. This makes the system game-able, especially by large token holders.
Enter Flexible Voting
The core problem identified in the cUNI situation was simple: governance token holders of most DAO's are forced to choose between deploying their tokens in DeFi and participating in Governance. This tradeoff was an unintentional consequence of the system's dsign. Could it be fixed? Yes, we fixed it, and to conceptualize the fix is easy.
We added a simple building block to governance: the ability for a delegate to split voting weight across For, Against, or Abstain when submitting votes to the Governor contract. This capability is especially useful when a contract serves as the voting delegate. We call this feature "Flexible Voting."
A deposit contract like Compound can delegate its voting weight to another "voting" contract. That contract in turn can implement its own set of rules enabling cUNI holders to vote on proposals.
Since the Flexible Voting enables the voting contract to split the pooled voting weight, the contract can accurately reflect the will of all cUNI holders. This mitigates the game-ability of the all-or-nothing approach and allows cUNI holders to participate in governance and DeFi simultaneously.
Flexible Voting is implemented as an extension to the "Governor" system pioneered by Compound and now used— in one variation or another— by many DAOs. In particular, we've implemented Flexible Voting as an extension to the OpenZeppelin Governor variant.
The original Governor interface proved too limited and rigid to support this change out of the box. Working with the OpenZeppelin team, we identified and implemented a way to expand the Governor's interface.
This change, which shipped in version 4.6.0 of the OpenZeppelin contracts, enables powerful constructs to be implemented as minimal extensions to the existing OZ Governor. We're grateful to the OpenZeppelin team for their support in this effort.
Our Flexible Voting extension to the Governor contract is now available as an open source project. The extension allows delegates to submit a payload to the Governor when voting, telling it how to split delegated voting weight across For, Against, and Abstain. The extension is fully tested and written to minimize gas overhead.
In order to illustrate how Flexible Voting would be incorporated into a hypothetical DeFi protocol, we've also implemented a proof-of-concept fractional pool. The contract demonstrates a use-case similar to cUNI or other DeFi protocols:
- Users can deposit their governance token and get a receipt token.
- Tokens in the pool can be "borrowed" against, changing the pool's balance
- Holders of receipt tokens can vote on proposals via the pool contract
- A single transaction submits all cumulative receipt token votes to the Governor
Flexible Voting Beyond DeFi
While pooled tokens in DeFi protocols were the genesis for this project, it turns out there are many other use cases that emerge from this seemingly simple building block. By enabling arbitrary contract logic to roll up the voting weights of disparate parties into a single delegated vote, many additional possibilities are unlocked. Having a contract act as the delegate also means these mechanisms can be implemented without introducing new trust assumptions. Some of the potential applications are just as exciting as the original motivation for Flexible Voting. Let's review some of them now.
Bridged Voting From L2
Ethereum's scaling ecosystem is expanding rapidly, with more and more activity taking place on Layer 2 solutions. This trend is likely to continue, and holders of governance tokens will be more and more likely to bridge them to various scaling networks.
To bridge mainnet tokens to an L2, you deposit the "real" tokens to a contract on L1, and are issued a bridged version on L2. While the bridged version is redeemable for the L1 version at any time, the "real" L1 token is held by the contract until a redemption occurs. This means users that opt to move or hold their tokens on L2 give up their governance rights, as the tokens are "owned" by a contract on the base layer, where the governance votes occur.
Flexible Voting allows for an elegant, trust minimized solution: the bridge contract delegates to another contract, and that contract votes proportionally on behalf of holders of the bridged version. With cross chain communication, holders of a governance token on an L2 could vote on L2— paying the cheaper gas prices available there— then be guaranteed this vote will be reflected on L1. A single cross chain transaction can roll up the votes of thousands of holders on L2 into a single delegated vote on L1.
Cheaper Subsidized Voting
Subsidized, signature based voting is a great way for DAOs to encourage governance participation for their members. It exists for Uniswap and other DAOs today, enabling users to vote for "free" by signing a message indicating their vote. This message is then submitted to the chain by a third party.
The third party still has to pay for the gas to submit the vote, and this is where signature based voting is limited. As gas prices rise, and more users participate, the costs associated with subsidizing thousands of votes will become prohibitive.
Flexible Voting offers a simple solution: many off-chain votes from token holders can be submitted at once. With the ability to split votes proportional to each individual holders preference, the third party can accurately reflect the will of many parties in a single transaction. This greatly reduces the overhead costs involved with offering subsidized off-chain voting, making it more sustainable and accessible.
Many users choose to custody their tokens with third parties, such as centralized exchanges or cold storage custodians. In most cases, this means users forfeit their governance participation rights, as the tokens are by definition held by another party.
Third party custodians don't typically offer customers the ability to vote. One reason for this is a practical one: how could they reflect the will of many disparate token holders when the tokens are held in the same custodial address(es)?
Flexible voting makes it much easier for centralized custodians to offer governance participation to their users. The custodian to could collect the votes of their users in a centralized database, then cast a single on-chain vote to reflect the proportional voting power of their customer's holdings.
Such a system would, of course, require the users trust the custodian to be honest about their vote. This seems like a reasonable tradeoff given the user has chosen to allow a third party to custody their assets in the first place. A custodian interested in transparency could choose to publish the individual votes they collected.
Flexible Voting should make it possible to build a privacy preserving governance voting system. Though it will be challenging to implement, the basic architecture is simple to understand: many holders can deposit their tokens into a Tornado-Cash like pool, where a zero knowledge proof is required to withdraw the tokens _or_ to cast a vote.
The pool delegates its voting power to a contract, and that contract accepts and verifies the zero-knowledge proofs, sent via relayers, which allow depositors to express their vote on any given proposal. After votes are tallied, a single transaction can be used to push all votes to governance. How each depositor to the pool voted would remain shielded.
We turn now to the hard work of seeing this powerful new governance feature adopted and put to use. ScopeLift hopes to continue pushing the project forward, but we can't do it alone. We're looking for help from the ecosystem to make Flexible Voting a reality for real DAOs.
For our part, we're hoping to implement real-world, production ready use cases for the Flexible Voting extension. Having the real use cases available and ready to go helps solve the chicken-and-the-egg adoption problem.
We're asking the ecosystem to help fund this development through mechanisms like grants or direct engagements with DAOs. If you work with or in a community that could benefit from these tools, please reach out.
The other side of the adoption coin is of course the DAOs themselves. The more DAOs that use the Flexible Voting construct, the more likely projects that leverage it will be built and adopted.
ScopeLift wants to see both new and existing DAOs adopt the extension. We also want to see DAO tooling that more directly supports it.
If you're a part of an existing DAO, getting ready to launch a new one, or working on tools for DAOs, don't hesitate to get in touch. ScopeLift is happy to help you execute on Flexible Voting.
ScopeLift is grateful to the Uniswap DAO community for supporting Governance innovation through the UGP. We're grateful for the opportunity to work on the Flexible Voting project. We believe the Flexible Voting construct has the potential to unlock powerful use cases for DAOs across the ecosystem.
We're excited to continue pushing this new building block forward, helping to see it adopted and leveraged to build useful things. We're asking the ecosystem to help support us in doing that. If you believe you can help, let us know.
Thanks to Noah Zinsmeister, Kevin Owocki, Tony Sheng, Francisco Giordano, Alana Levin, Matt Solomon and Ed Mazurek for providing feedback on a draft of this post. Thanks to David Laprade for his contributions to this project and this post. Thanks to Gary Ghayrat for creating the included diagram.