Currently, ARB stored in lending vaults does not count into a user’s voting power. This hurts governance engagement, as the community must choose between using their ARB or voting with it.
At QiDao, we want to provide access to liquidity to both users and protocols that will hold ARB long term. To maintain governance participation by this community, we should count the ARB held in QiDao vaults when tallying voting power.
ARB QiDao Vault contract: 0x950eceee9e7d7366a24fc9d2ed4c0c37d17a0fa9
QiDao is a collateral-backed stablecoin project (CDP). This means that user deposits are siloed from other users. Unlike with peer-to-peer lending platforms, collateral deposited cannot be used to short that token. So ARB deposited would not be liquidity for those betting against ARB.
For many Arbitrum projects, the airdropped ARB represents a significant addition to their treasury. We want to enable these projects to be able to finance their projects with this value without dumping ARB or using it as a reward token. By minting stablecoins against ARB, you can both hodl and spend. Interest rates have been set low to allow for greater benefit to the Arbitrum community,
Currently, ARB stored in lending vaults does not count into a user’s voting power. This hurts governance engagement, as the community must choose between using their ARB or voting with it.
At QiDao, we want to provide access to liquidity to both users and protocols that will hold ARB long term. To maintain governance participation by this community, we should count the ARB held in QiDao vaults when tallying voting power.
ARB QiDao Vault contract: 0x950eceee9e7d7366a24fc9d2ed4c0c37d17a0fa9
QiDao is a collateral-backed stablecoin project (CDP). This means that user deposits are siloed from other users. Unlike with peer-to-peer lending platforms, collateral deposited cannot be used to short that token. So ARB deposited would not be liquidity for those betting against ARB.
For many Arbitrum projects, the airdropped ARB represents a significant addition to their treasury. We want to enable these projects to be able to finance their projects with this value without dumping ARB or using it as a reward token. By minting stablecoins against ARB, you can both hodl and spend. Interest rates have been set low to allow for greater benefit to the Arbitrum community,
Considering the unique characteristics of QiDao vaults and their role in providing liquidity without affecting shorting, it seems reasonable to include ARB held in QiDao vaults when calculating voting power in the Arbitrum DAO. This would support governance engagement and enable financing for Arbitrum projects while maintaining a balance.
Considering the unique characteristics of QiDao vaults and their role in providing liquidity without affecting shorting, it seems reasonable to include ARB held in QiDao vaults when calculating voting power in the Arbitrum DAO. This would support governance engagement and enable financing for Arbitrum projects while maintaining a balance.
Updated proposal
Currently, ARB stored in lending vaults does not count into a user’s voting power. This hurts governance engagement, as the community must choose between using their ARB or voting with it.
Updated proposal
Currently, ARB stored in lending vaults does not count into a user’s voting power. This hurts governance engagement, as the community must choose between using their ARB or voting with it.
At QiDao, we want to provide access to liquidity to both users and protocols that will hold ARB long term. To maintain governance participation by this community, we should count the ARB held in QiDao vaults when tallying voting power.
It is important to note that most protocols do not have the capability to delegate to individual users from their contracts. This is why it’s important to add ARB use cases to the Snapshot strategies page.
ARB QiDao Vault contract: 0x950eceee9e7d7366a24fc9d2ed4c0c37d17a0fa9
Every CDP works differently, so solutions for each will vary. The current amount of large-scale CDP stablecoin projects on Arbitrum is quite manageable. For this reason, it is best that each CDP stablecoin propose to be whitelisted into the governance power tally. Each project should also provide the strategy to be placed into the Snapshot.org settings. This will reduce operations work for Arbitrum's team. It will also make this process more transparent.
QiDao is a collateral-backed stablecoin project (CDP). This means that user deposits are siloed from other users. Unlike with peer-to-peer lending platforms, collateral deposited cannot be used to short that token. So ARB deposited would not be liquidity for those betting against ARB.
For many Arbitrum projects, the airdropped ARB represents a significant addition to their treasury. We want to enable these projects to be able to finance their projects with this value without dumping ARB or using it as a reward token. By minting stablecoins against ARB, you can both hodl and spend. Interest rates have been set low to allow for greater benefit to the Arbitrum community.
The strategy implementation only requires the Snapshot page admins to go to settings >> strategies >> "+Add"
It is not possible for the vault contract to vote. ARB stored in the contract can only be managed by the individual depositors. As a result, there is no angle for double counting.
I was told on the Arbitrum Discord that only delegation happens on Tally. Then Snapshot is for voting (all AIPs have occurred on Snapshot so far).
We definitely dont want this to look like it's for one protocol, but it's important to acknowledge that every protocol works differently. As a result we need specific solutions for each.
How about we organize a community call on this?
thank you for your support ser!
the reason we didnt make it a broader proposal for all CDP stablecoins/platforms is that every protocol functions differently. In order to actually implement this proposal, we're working with Snapshot to come up with a simple "strategy" on Snapshot's setting to add this count. Each new project will have to come up with custom strategies. Though forks, such as uniswap forks, may be able to use the same code as that being used by the original projects.
There is no native functionality for this on our contracts (or on DEXs/lending markets). That's why I think it would be better to set some standards ourselves as a community.
Given that voting occurs via snapshot, the adding of contracts is actually very simple. All we need to do is add a "strategy" on the settings tab on Snapshot. This can be done for accepted protocols (i.e. Uniswap, Aave, QiDao, etc).
There is no native functionality for this on our contracts (or on DEXs/lending markets). That's why I think it would be better to set some standards ourselves as a community.
Given that voting occurs via snapshot, the adding of contracts is actually very simple. All we need to do is add a "strategy" on the settings tab on Snapshot. This can be done for accepted protocols (i.e. Uniswap, Aave, QiDao, etc).
It is important to note that CDP stablecoins and DEXs cannot be gamed in the ways described under the flexible voting replies below. I personally always side with the simplest solutions. Having a lot of experience with Snapshot in particular, I think this is the best course of action for DEXs and CDP stablecoins in particular.
Would fully back this proposal, and not limit this to QiDAO. I don't think any project should be penalised for holding ARB in their contracts and adding utility, and should be recognised as a contributor to the ecosystem and be able to wield that voting power on behalf of their own communities.
The risk of these projects holding control with significant voting power is, to me, no different to the risk of individual wallet addresses. Although if this is a concern for some then adding into governance a simple mechanism whereby these contracts are excluded from future governance votes that pertain to removing or reducing these voting powers.
If i can understand. This proposal it's to make something like liquid staking or liquid liquidity? Sounds great, and it could be another type of revenue to the token, and not only for governance. But what do you think to also mint mARB, like the tokens that you already minted in Polygon
Is it not possible for the QiDao contracts to allow the user to direct the contract to delegate its balance of ARB (in proportion to the user's claim) to a delegate that the user wants?
I'm asking as it seems better to keep the governance set of contracts impartial and set a standard of implementing this at the application layer as these cases will surely set a precedent, and I doubt there won't be more vaults in a similar situation in the future on Arbitrum One.
Is it not possible for the QiDao contracts to allow the user to direct the contract to delegate its balance of ARB (in proportion to the user's claim) to a delegate that the user wants?
I'm asking as it seems better to keep the governance set of contracts impartial and set a standard of implementing this at the application layer as these cases will surely set a precedent, and I doubt there won't be more vaults in a similar situation in the future on Arbitrum One.
Apologies if I misread any of the existing thread and my question was already answered.
it's not much different from the existing ARB voting power calculations. It's just another strategy that u can add on Snapshot, all out of the box.
we should go ahead and create a standard for CDPs, as they work differently compared to LPs and peer-to-peer lending platforms.
Broad process
Hey, I think it's very smart to include the LPs as well. That way we dont disincentivize providing liquidity. I wonder if that idea includes deposits on lending markets or CDP stablecoins.
in regards to flexible voting, I think going with the simplest solution is always best. The easiest solution here would be to query a user's balance in a contract. That way we dont add delegation contracts to existing infra. Adding an extra layer of smart contract risk to existing solutions could have unwanted second order effects.
Hey, I think it's very smart to include the LPs as well. That way we dont disincentivize providing liquidity. I wonder if that idea includes deposits on lending markets or CDP stablecoins.
in regards to flexible voting, I think going with the simplest solution is always best. The easiest solution here would be to query a user's balance in a contract. That way we dont add delegation contracts to existing infra. Adding an extra layer of smart contract risk to existing solutions could have unwanted second order effects.
This solution is particular to CDP stablecoins like MAI, since you dont have the cToken model that peer-to-peer lending platforms do.
for further reading, here are a couple of links that might be helpful for additional context:
ARB risk assessment by QiDao Risk Committee: https://mai.watch/en/assessments/arb-arbitrum
QiDao documentation: https://docs.mai.finance/introduction-1
ARB vault parameters:
Updated proposal
Currently, ARB stored in lending vaults does not count into a user’s voting power. This hurts governance engagement, as the community must choose between using their ARB or voting with it.
Updated proposal
Currently, ARB stored in lending vaults does not count into a user’s voting power. This hurts governance engagement, as the community must choose between using their ARB or voting with it.
At QiDao, we want to provide access to liquidity to both users and protocols that will hold ARB long term. To maintain governance participation by this community, we should count the ARB held in QiDao vaults when tallying voting power.
It is important to note that most protocols do not have the capability to delegate to individual users from their contracts. This is why it’s important to add ARB use cases to the Snapshot strategies page.
ARB QiDao Vault contract: 0x950eceee9e7d7366a24fc9d2ed4c0c37d17a0fa9
Every CDP works differently, so solutions for each will vary. The current amount of large-scale CDP stablecoin projects on Arbitrum is quite manageable. For this reason, it is best that each CDP stablecoin propose to be whitelisted into the governance power tally. Each project should also provide the strategy to be placed into the Snapshot.org settings. This will reduce operations work for Arbitrum's team. It will also make this process more transparent.
QiDao is a collateral-backed stablecoin project (CDP). This means that user deposits are siloed from other users. Unlike with peer-to-peer lending platforms, collateral deposited cannot be used to short that token. So ARB deposited would not be liquidity for those betting against ARB.
For many Arbitrum projects, the airdropped ARB represents a significant addition to their treasury. We want to enable these projects to be able to finance their projects with this value without dumping ARB or using it as a reward token. By minting stablecoins against ARB, you can both hodl and spend. Interest rates have been set low to allow for greater benefit to the Arbitrum community.
The strategy implementation only requires the Snapshot page admins to go to settings >> strategies >> "+Add"
It is not possible for the vault contract to vote. ARB stored in the contract can only be managed by the individual depositors. As a result, there is no angle for double counting.
I was told on the Arbitrum Discord that only delegation happens on Tally. Then Snapshot is for voting (all AIPs have occurred on Snapshot so far).
We definitely dont want this to look like it's for one protocol, but it's important to acknowledge that every protocol works differently. As a result we need specific solutions for each.
How about we organize a community call on this?
thank you for your support ser!
the reason we didnt make it a broader proposal for all CDP stablecoins/platforms is that every protocol functions differently. In order to actually implement this proposal, we're working with Snapshot to come up with a simple "strategy" on Snapshot's setting to add this count. Each new project will have to come up with custom strategies. Though forks, such as uniswap forks, may be able to use the same code as that being used by the original projects.
There is no native functionality for this on our contracts (or on DEXs/lending markets). That's why I think it would be better to set some standards ourselves as a community.
Given that voting occurs via snapshot, the adding of contracts is actually very simple. All we need to do is add a "strategy" on the settings tab on Snapshot. This can be done for accepted protocols (i.e. Uniswap, Aave, QiDao, etc).
There is no native functionality for this on our contracts (or on DEXs/lending markets). That's why I think it would be better to set some standards ourselves as a community.
Given that voting occurs via snapshot, the adding of contracts is actually very simple. All we need to do is add a "strategy" on the settings tab on Snapshot. This can be done for accepted protocols (i.e. Uniswap, Aave, QiDao, etc).
It is important to note that CDP stablecoins and DEXs cannot be gamed in the ways described under the flexible voting replies below. I personally always side with the simplest solutions. Having a lot of experience with Snapshot in particular, I think this is the best course of action for DEXs and CDP stablecoins in particular.
Would fully back this proposal, and not limit this to QiDAO. I don't think any project should be penalised for holding ARB in their contracts and adding utility, and should be recognised as a contributor to the ecosystem and be able to wield that voting power on behalf of their own communities.
The risk of these projects holding control with significant voting power is, to me, no different to the risk of individual wallet addresses. Although if this is a concern for some then adding into governance a simple mechanism whereby these contracts are excluded from future governance votes that pertain to removing or reducing these voting powers.
If i can understand. This proposal it's to make something like liquid staking or liquid liquidity? Sounds great, and it could be another type of revenue to the token, and not only for governance. But what do you think to also mint mARB, like the tokens that you already minted in Polygon
Is it not possible for the QiDao contracts to allow the user to direct the contract to delegate its balance of ARB (in proportion to the user's claim) to a delegate that the user wants?
I'm asking as it seems better to keep the governance set of contracts impartial and set a standard of implementing this at the application layer as these cases will surely set a precedent, and I doubt there won't be more vaults in a similar situation in the future on Arbitrum One.
Is it not possible for the QiDao contracts to allow the user to direct the contract to delegate its balance of ARB (in proportion to the user's claim) to a delegate that the user wants?
I'm asking as it seems better to keep the governance set of contracts impartial and set a standard of implementing this at the application layer as these cases will surely set a precedent, and I doubt there won't be more vaults in a similar situation in the future on Arbitrum One.
Apologies if I misread any of the existing thread and my question was already answered.
it's not much different from the existing ARB voting power calculations. It's just another strategy that u can add on Snapshot, all out of the box.
we should go ahead and create a standard for CDPs, as they work differently compared to LPs and peer-to-peer lending platforms.
Broad process
Hey, I think it's very smart to include the LPs as well. That way we dont disincentivize providing liquidity. I wonder if that idea includes deposits on lending markets or CDP stablecoins.
in regards to flexible voting, I think going with the simplest solution is always best. The easiest solution here would be to query a user's balance in a contract. That way we dont add delegation contracts to existing infra. Adding an extra layer of smart contract risk to existing solutions could have unwanted second order effects.
Hey, I think it's very smart to include the LPs as well. That way we dont disincentivize providing liquidity. I wonder if that idea includes deposits on lending markets or CDP stablecoins.
in regards to flexible voting, I think going with the simplest solution is always best. The easiest solution here would be to query a user's balance in a contract. That way we dont add delegation contracts to existing infra. Adding an extra layer of smart contract risk to existing solutions could have unwanted second order effects.
This solution is particular to CDP stablecoins like MAI, since you dont have the cToken model that peer-to-peer lending platforms do.
for further reading, here are a couple of links that might be helpful for additional context:
ARB risk assessment by QiDao Risk Committee: https://mai.watch/en/assessments/arb-arbitrum
QiDao documentation: https://docs.mai.finance/introduction-1
ARB vault parameters:
I believe there was a similar proposal previously for counting voting power from multiple vaults. https://forum.arbitrum.foundation/t/proposal-include-lps-in-gov-voting/11615 What do you think of that particular proposal and potentially including QiDao in it alongside other protocols?
Also one of the suggestions was using Flexible Voting's approach in order to achieve that. Do you hold any thoughts around that?
https://forum.arbitrum.foundation/t/proposal-include-lps-in-gov-voting/11615/7
I believe there was a similar proposal previously for counting voting power from multiple vaults. https://forum.arbitrum.foundation/t/proposal-include-lps-in-gov-voting/11615 What do you think of that particular proposal and potentially including QiDao in it alongside other protocols?
Also one of the suggestions was using Flexible Voting's approach in order to achieve that. Do you hold any thoughts around that?
https://forum.arbitrum.foundation/t/proposal-include-lps-in-gov-voting/11615/7
Would be awesome to get your input there.
I believe there was a similar proposal previously for counting voting power from multiple vaults. https://forum.arbitrum.foundation/t/proposal-include-lps-in-gov-voting/11615 What do you think of that particular proposal and potentially including QiDao in it alongside other protocols?
Also one of the suggestions was using Flexible Voting's approach in order to achieve that. Do you hold any thoughts around that?
https://forum.arbitrum.foundation/t/proposal-include-lps-in-gov-voting/11615/7
I believe there was a similar proposal previously for counting voting power from multiple vaults. https://forum.arbitrum.foundation/t/proposal-include-lps-in-gov-voting/11615 What do you think of that particular proposal and potentially including QiDao in it alongside other protocols?
Also one of the suggestions was using Flexible Voting's approach in order to achieve that. Do you hold any thoughts around that?
https://forum.arbitrum.foundation/t/proposal-include-lps-in-gov-voting/11615/7
Would be awesome to get your input there.
That is interesting. I would caution against doing anything for votes that are meant to be decisions that will create a discrepancy between Snapshot and Tally voting weight.
I do like the idea of using the Snapshot out-of-the-box features for creative Snapshot uses which aren't meant to represent a vote which will then move to Tally.
Does this require real-time detection? If yes, that is why I think the flexible voting contract built by ScopeLift which is audited is the best bet.
This is an option more generalized to allow anyone to remain participating in governance while using their tokens to earn yield. It was passed by Gitcoin and Aave, so it is already built and ready to go.
This is an option more generalized to allow anyone to remain participating in governance while using their tokens to earn yield. It was passed by Gitcoin and Aave, so it is already built and ready to go.
The purpose of this post is to introduce Flexible Voting and begin the discussion about its adoption by the Gitcoin DAO. Flexible Voting is an extension to the Governor contract. It allows for the construction of new mechanisms which make governance participation easier, cheaper, and more accessible for GTC holders.
Flexible Voting was developed by ScopeLift as part of our grant from the Uniswap Grants Program . Before explaining more about Flexible Voting, let me introduce ScopeLift for anyone whose not familiar with us.
ScopeLift is a dev shop focused on crypto. We’re a small technical team with many years of EVM engineering experience. We’ve had the pleasure of working with many great clients including Uniswap, Optimism, Cozy, Endaoment, POAP, and others.
ScopeLift is a long time friend friend of Gitcoin. W’ve had the privilege of contributing to Gitcoin in various ways over the last few years, including helping to build the cart based checkout experience, the bulk checkout smart contract, the BrightID integration, the integration with zkSync, and the first iteration of dGrants.
We’re also the team behind Umbra , a stealth address system developed with grant funding from the EF, MolochDAO, and of course Gitcoin :slight_smile:
ScopeLift received a UGP grant earlier this year to work on Governance related projects. One of those projects is Flexible Voting, which is the subject of this post.
Flexible Voting is an extension to the Governor contracts that enables delegates to split their voting weight across For, Against, and Abstain on any given proposal. This capability is especially useful when a contract serves as the delegate.
By enabling arbitrary contract logic to roll up the voting weight of disparate parties into a single delegated vote, many possibilities are unlocked. Having a contract act as the delegate also means these mechanisms can be implemented without introducing new trust assumptions.
The inspiration for Flexible Voting came from cUNI (Compound UNI). When a UNI holder deposits their tokens into Compound, they lose the ability to participate in Governance. Attempts to mitigate this required trust and were gameable . Any holder of GTC who wants to deploy their tokens in DeFi would experience the same issue.
Flexible Governance fixes this problem. 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 DeFi depositors to vote on proposals.
In addition to allowing token holders to vote while their GTC is active in DeFi, Flexible Voting enables many more use cases, such as:
For a much more in-depth introduction to Flexible Voting, how we built it, and what it enables, check out post on the ScopeLift blog .
Flexible Voting is implemented as an extension to the OpenZeppelin Governor contract. It is open source . Adopting it would require a carefully crafted governance proposal to be submitted and voted on. Since the DAO is actively considering an upgrade to the OpenZeppelin Governor, now would be the perfect opportunity to adopt Flexible Voting, and ScopeLift is committed to helping should the DAO choose to do this.
We’d love to hear your feedback. If you’re a member of the community and you’d like to help us move Flexible Voting forward for Gitcoin, please get in touch.
For our part, we’re working to expand the system’s capability by implementing some of the concrete use cases which Flexible Voting makes possible. We’re working to see Flexible Voting, which is backwards compatible with existing Governor tooling, directly and fully supported. We’re also proposing Flexible Voting to other DAOs, including Uniswap, which funded its initial development.
If you’d like to help us build it, fund it, or get it adopted by another community you’re a part of, reach out!
The proposal seems reasonable, although I think it needs some more thought (at least on my part).
Especially, @Benjamin.lens you mention a few times that voting happens on Snapshot, but that's actually not true, what we have on Snapshot is just a temperature check and the 'real' voting happens on-chain on Tally. As @DisruptionJoe already mentioned, the discrepancy between Tally and Snapshot might be confusing and dangerous - we've already had a taste of this in the infamous Uniswap bridge vote.
The proposal seems reasonable, although I think it needs some more thought (at least on my part).
Especially, @Benjamin.lens you mention a few times that voting happens on Snapshot, but that's actually not true, what we have on Snapshot is just a temperature check and the 'real' voting happens on-chain on Tally. As @DisruptionJoe already mentioned, the discrepancy between Tally and Snapshot might be confusing and dangerous - we've already had a taste of this in the infamous Uniswap bridge vote.
I am also reluctant to vote for something that favours just one protocol, would prefer some universal approach or at least to invite into the discussion other protocols that might be interested in that.
At first glance, I think it would be best to do this in a more general way if the DAO wanted to do it at all.
Would Flexible Voting make this possible for QiDAO or any non-QiDAO vaults?
Is there a reason why we would only want to extend this benefit to QiDAO vaults?
I would support ARB used to back MAI as votable, as it is locked up, unlikely to be double counted, and still transferable.
As @fred mentioned, Im all for starting to use ARB put to work as votable positions.
As we discussed today with @Benjamin.lens, the Tally vote is actually more important than the Snapshot vote (although both are meaningful), so we need a different solution for that. I proposed to make it a point in an agenda for an upcoming DAO Governance Call that was proposed here: https://forum.arbitrum.foundation/t/interest-in-a-monthly-governance-call/14046/ and let's figure out how can we approach it.
That is interesting. I would caution against doing anything for votes that are meant to be decisions that will create a discrepancy between Snapshot and Tally voting weight.
I do like the idea of using the Snapshot out-of-the-box features for creative Snapshot uses which aren't meant to represent a vote which will then move to Tally.
Does this require real-time detection? If yes, that is why I think the flexible voting contract built by ScopeLift which is audited is the best bet.
This is an option more generalized to allow anyone to remain participating in governance while using their tokens to earn yield. It was passed by Gitcoin and Aave, so it is already built and ready to go.
This is an option more generalized to allow anyone to remain participating in governance while using their tokens to earn yield. It was passed by Gitcoin and Aave, so it is already built and ready to go.
The purpose of this post is to introduce Flexible Voting and begin the discussion about its adoption by the Gitcoin DAO. Flexible Voting is an extension to the Governor contract. It allows for the construction of new mechanisms which make governance participation easier, cheaper, and more accessible for GTC holders.
Flexible Voting was developed by ScopeLift as part of our grant from the Uniswap Grants Program . Before explaining more about Flexible Voting, let me introduce ScopeLift for anyone whose not familiar with us.
ScopeLift is a dev shop focused on crypto. We’re a small technical team with many years of EVM engineering experience. We’ve had the pleasure of working with many great clients including Uniswap, Optimism, Cozy, Endaoment, POAP, and others.
ScopeLift is a long time friend friend of Gitcoin. W’ve had the privilege of contributing to Gitcoin in various ways over the last few years, including helping to build the cart based checkout experience, the bulk checkout smart contract, the BrightID integration, the integration with zkSync, and the first iteration of dGrants.
We’re also the team behind Umbra , a stealth address system developed with grant funding from the EF, MolochDAO, and of course Gitcoin :slight_smile:
ScopeLift received a UGP grant earlier this year to work on Governance related projects. One of those projects is Flexible Voting, which is the subject of this post.
Flexible Voting is an extension to the Governor contracts that enables delegates to split their voting weight across For, Against, and Abstain on any given proposal. This capability is especially useful when a contract serves as the delegate.
By enabling arbitrary contract logic to roll up the voting weight of disparate parties into a single delegated vote, many possibilities are unlocked. Having a contract act as the delegate also means these mechanisms can be implemented without introducing new trust assumptions.
The inspiration for Flexible Voting came from cUNI (Compound UNI). When a UNI holder deposits their tokens into Compound, they lose the ability to participate in Governance. Attempts to mitigate this required trust and were gameable . Any holder of GTC who wants to deploy their tokens in DeFi would experience the same issue.
Flexible Governance fixes this problem. 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 DeFi depositors to vote on proposals.
In addition to allowing token holders to vote while their GTC is active in DeFi, Flexible Voting enables many more use cases, such as:
For a much more in-depth introduction to Flexible Voting, how we built it, and what it enables, check out post on the ScopeLift blog .
Flexible Voting is implemented as an extension to the OpenZeppelin Governor contract. It is open source . Adopting it would require a carefully crafted governance proposal to be submitted and voted on. Since the DAO is actively considering an upgrade to the OpenZeppelin Governor, now would be the perfect opportunity to adopt Flexible Voting, and ScopeLift is committed to helping should the DAO choose to do this.
We’d love to hear your feedback. If you’re a member of the community and you’d like to help us move Flexible Voting forward for Gitcoin, please get in touch.
For our part, we’re working to expand the system’s capability by implementing some of the concrete use cases which Flexible Voting makes possible. We’re working to see Flexible Voting, which is backwards compatible with existing Governor tooling, directly and fully supported. We’re also proposing Flexible Voting to other DAOs, including Uniswap, which funded its initial development.
If you’d like to help us build it, fund it, or get it adopted by another community you’re a part of, reach out!
The proposal seems reasonable, although I think it needs some more thought (at least on my part).
Especially, @Benjamin.lens you mention a few times that voting happens on Snapshot, but that's actually not true, what we have on Snapshot is just a temperature check and the 'real' voting happens on-chain on Tally. As @DisruptionJoe already mentioned, the discrepancy between Tally and Snapshot might be confusing and dangerous - we've already had a taste of this in the infamous Uniswap bridge vote.
The proposal seems reasonable, although I think it needs some more thought (at least on my part).
Especially, @Benjamin.lens you mention a few times that voting happens on Snapshot, but that's actually not true, what we have on Snapshot is just a temperature check and the 'real' voting happens on-chain on Tally. As @DisruptionJoe already mentioned, the discrepancy between Tally and Snapshot might be confusing and dangerous - we've already had a taste of this in the infamous Uniswap bridge vote.
I am also reluctant to vote for something that favours just one protocol, would prefer some universal approach or at least to invite into the discussion other protocols that might be interested in that.
At first glance, I think it would be best to do this in a more general way if the DAO wanted to do it at all.
Would Flexible Voting make this possible for QiDAO or any non-QiDAO vaults?
Is there a reason why we would only want to extend this benefit to QiDAO vaults?
I would support ARB used to back MAI as votable, as it is locked up, unlikely to be double counted, and still transferable.
As @fred mentioned, Im all for starting to use ARB put to work as votable positions.
As we discussed today with @Benjamin.lens, the Tally vote is actually more important than the Snapshot vote (although both are meaningful), so we need a different solution for that. I proposed to make it a point in an agenda for an upcoming DAO Governance Call that was proposed here: https://forum.arbitrum.foundation/t/interest-in-a-monthly-governance-call/14046/ and let's figure out how can we approach it.
