Summary
Despite being one of the most prominent DeFi protocols, Uniswap’s outstanding voting power does not necessarily translate into active governance participation. In fact, many top delegates with considerable voting power have less than 50% vote participation rate, and some even as low as 10% or 0%. While there have been previous campaigns to encourage delegation by large UNI holders, we have seen that further delegate accountability is needed as many of those who received large delegations barely participated, if at all.
In healthy governance environments, proactive delegates wield significant voting power, ensuring malicious votes are prevented and quorum requirements are met.
Therefore, this proposal requests the Uniswap Foundation delegate 2.5 million UNI to each of 4 active yet underrepresented delegates selected based on the criteria outlined below. To ensure further accountability, each delegate must maintain a 80% participation rate at a minimum (as explained further in Participation Requirements) or is subject to undelegation via the Franchiser contract explained below. In addition, there will 1 year term so the community can revisit for improvements and lessons learned. And if a received delegate is removed without fulling this 1 year term, the role won’t be filled.
Landscape of Uniswap Governance
Source: Butter
Despite numerous improvements to Uniswap’s governance, there are still several areas that require further improvement. One prominent area is governance participation, which has witnessed a downward trend compared to late 2022 and early 2023.
Another issue is many large delegates are now inactive, and the delegators who entrusted them with delegation are either unaware about this inactivity or simply do not care. For example, there is currently several delegates with more than 2.5 million UNI delegated who never even voted onchain according to Tally, see the screenshot below.
Source: Tally
Therefore, further distributing governance power to active but underrepresented delegates is a positive step forward ensuring governance is more active, resilient, and robust.
Participation Requirements
Application Criteria
Next Steps
Other Clarification
-The term will be 1 year from when 2.5 M UNI is delegated.
-Should the onchain vote be approved but there are three or fewer qualified applicants because there are not enough qualified applicants, there WON'T be a subsequent application period and Snapshot vote after the initial vote to fill the remaining available recipients.
-Should the onchain vote be approved and there are qualified applicants but one or more of them are disqualified in the future due to their low vote participation, there will NOT be a new application and snapshot vote to give the opportunity to another delegate.
-As mentioned by in a previous proposal seeking UNI delegation, there will be deployment of at max four new Franchiser contracts, each one funded with 2.5M UNI (10M UNI total). The owner of these Franchiser instance’s would be the Timelock, while the at max four delegates chosen through the voting process outlined above can act as the delegatees.
Summary
Despite being one of the most prominent DeFi protocols, Uniswap’s outstanding voting power does not necessarily translate into active governance participation. In fact, many top delegates with considerable voting power have less than 50% vote participation rate, and some even as low as 10% or 0%. While there have been previous campaigns to encourage delegation by large UNI holders, we have seen that further delegate accountability is needed as many of those who received large delegations barely participated, if at all.
In healthy governance environments, proactive delegates wield significant voting power, ensuring malicious votes are prevented and quorum requirements are met.
Therefore, this proposal requests the Uniswap Foundation delegate 2.5 million UNI to each of 4 active yet underrepresented delegates selected based on the criteria outlined below. To ensure further accountability, each delegate must maintain a 80% participation rate at a minimum (as explained further in Participation Requirements) or is subject to undelegation via the Franchiser contract explained below. In addition, there will 1 year term so the community can revisit for improvements and lessons learned. And if a received delegate is removed without fulling this 1 year term, the role won’t be filled.
Landscape of Uniswap Governance
Source: Butter
Despite numerous improvements to Uniswap’s governance, there are still several areas that require further improvement. One prominent area is governance participation, which has witnessed a downward trend compared to late 2022 and early 2023.
Another issue is many large delegates are now inactive, and the delegators who entrusted them with delegation are either unaware about this inactivity or simply do not care. For example, there is currently several delegates with more than 2.5 million UNI delegated who never even voted onchain according to Tally, see the screenshot below.
Source: Tally
Therefore, further distributing governance power to active but underrepresented delegates is a positive step forward ensuring governance is more active, resilient, and robust.
Participation Requirements
Application Criteria
Next Steps
Other Clarification
-The term will be 1 year from when 2.5 M UNI is delegated.
-Should the onchain vote be approved but there are three or fewer qualified applicants because there are not enough qualified applicants, there WON'T be a subsequent application period and Snapshot vote after the initial vote to fill the remaining available recipients.
-Should the onchain vote be approved and there are qualified applicants but one or more of them are disqualified in the future due to their low vote participation, there will NOT be a new application and snapshot vote to give the opportunity to another delegate.
-As mentioned by in a previous proposal seeking UNI delegation, there will be deployment of at max four new Franchiser contracts, each one funded with 2.5M UNI (10M UNI total). The owner of these Franchiser instance’s would be the Timelock, while the at max four delegates chosen through the voting process outlined above can act as the delegatees.
https://gov.uniswap.org/t/temperature-check-delegation-of-uni-to-active-but-underrepresented-delegates/22238/2?u=kaereste
https://gov.uniswap.org/t/temperature-check-delegation-of-uni-to-active-but-underrepresented-delegates/22238/2?u=kaereste
Yazzzz! Let's do that. Hoping for support.
A Twitter space sounds like a great idea. Let me know how 404 DAO can support it.
Yazzzz! Let's do that. Hoping for support.
A Twitter space sounds like a great idea. Let me know how 404 DAO can support it.
Delegates have confirmed via messages that their address is correct but yes, they can check it for errors here.
Confirming StableLab 's is correct
| # | Name | Votes Won | Voting Power (at the time of the snapshot voting) | Needed Delegation (UNI) | Total Delegated (UNI) | Address (where UNI will be delegated to) |
|---|---|---|---|---|---|---|
| 1 | 404 DAO | 5786355 | 250000 | 2250000 | 2500000 | 0xE93D59CC0bcECFD4ac204827eF67c5266079E2b5 |
| 2 | Wintermute Governance | 5643733 | 600000 | 1900000 | 2500000 | 0xB933AEe47C438f22DE0747D57fc239FE37878Dd1 |
| 3 | PGov | 4744613 | 250000 | 2250000 | 2500000 | 0x3fb19771947072629c8eee7995a2ef23b72d4c8a |
| 4 | StableLab | 4489610 | 142 | 2499858 | 2500000 | 0xECC2a9240268BC7a26386ecB49E1Befca2706AC9 |
| 5 | Keyrock | 3252294 | 10000 | 493972 | 503971.7015 | 0x1855f41B8A86e701E33199DE7C25d3e3830698ba |
| 6 | Karpatkey | 2980075 | 467000 | 452626 | 919625.9675 | 0x8787FC2De4De95c53e5E3a4e5459247D9773ea52 |
| 7 | atiselsts.eth | 1010931 | 250000 | 153544 | 403544.3309 | 0xAac35d953Ef23aE2E61a866ab93deA6eC0050bcD |
To clarify, scam or malicious votes do count toward participation rate (it's obvious but we live in DAO world where some might take it literally).
As such proposal noted by @eek637
https://twitter.com/eek637/status/1731718589370008036?t=OHkJZp_0JCR13IUKuID9qg&s=19
Our address is correct, thanks!
Confirming that the address for karpatkey is correct.
Can we get the delegates to post their addresses in this thread just to confirm the calldatas for the proposal pls?
@Doo_StableLab @404DAO @rikagoldberg @WintermuteGovernance @PGov @Juanbug @0xkeyrock.eth @kpk @coltron.eth @kfx
StableLab team has made a simple dune dashboard to keep track of Uniswap delegations via Franchiser contract. https://dune.com/queries/3239957
Currently in the dashboard, the address 0xa37131410a76791f4a0210e91edd554d85afb4d4 , which received 2.5 mil UNI in delegation is Uniswap Foundation multisig, which was approved last year.
Confirming 404 DAO's address is correct
My address is correct.
Confirming ours is correct.
Copying from post on competition snapshot poll.
The poll has closed and thanks everyone for voting.
Confirming Top 4 Delegates are 404 DAO, Wintermute Governance, PGov, and StableLab, and will get delegation till 2.5 M is achieved. The rest of UNI (out of 10 M) will be split among Keyrock, Karpatkey, and atiselsts.eth proportional to their votes won.
Nope, has to be called by the owner which is the Timelock in this case - would require a vote.
Thank you for the column. That will indeed be helpful 🙏 I will add it to the excel as well
We just confirmed with qualified delegates their address and shared the draft for the onchain proposal for the feedback.
One area I am a bit stuck on is code with the onchain proposal. A delegate asked me whether the code is ready and simulated. If it's required for the proposal, I am looking for ways to get supported with such.
We just confirmed with qualified delegates their address and shared the draft for the onchain proposal for the feedback.
One area I am a bit stuck on is code with the onchain proposal. A delegate asked me whether the code is ready and simulated. If it's required for the proposal, I am looking for ways to get supported with such.
Once it's ready, we will reach out to delegates who are able to post it onchain for us.
Delegates have confirmed via messages that their address is correct but yes, they can check it for errors here.
Confirming StableLab 's is correct
| # | Name | Votes Won | Voting Power (at the time of the snapshot voting) | Needed Delegation (UNI) | Total Delegated (UNI) | Address (where UNI will be delegated to) |
|---|---|---|---|---|---|---|
| 1 | 404 DAO | 5786355 | 250000 | 2250000 | 2500000 | 0xE93D59CC0bcECFD4ac204827eF67c5266079E2b5 |
| 2 | Wintermute Governance | 5643733 | 600000 | 1900000 | 2500000 | 0xB933AEe47C438f22DE0747D57fc239FE37878Dd1 |
| 3 | PGov | 4744613 | 250000 | 2250000 | 2500000 | 0x3fb19771947072629c8eee7995a2ef23b72d4c8a |
| 4 | StableLab | 4489610 | 142 | 2499858 | 2500000 | 0xECC2a9240268BC7a26386ecB49E1Befca2706AC9 |
| 5 | Keyrock | 3252294 | 10000 | 493972 | 503971.7015 | 0x1855f41B8A86e701E33199DE7C25d3e3830698ba |
| 6 | Karpatkey | 2980075 | 467000 | 452626 | 919625.9675 | 0x8787FC2De4De95c53e5E3a4e5459247D9773ea52 |
| 7 | atiselsts.eth | 1010931 | 250000 | 153544 | 403544.3309 | 0xAac35d953Ef23aE2E61a866ab93deA6eC0050bcD |
To clarify, scam or malicious votes do count toward participation rate (it's obvious but we live in DAO world where some might take it literally).
As such proposal noted by @eek637
https://twitter.com/eek637/status/1731718589370008036?t=OHkJZp_0JCR13IUKuID9qg&s=19
Our address is correct, thanks!
Confirming that the address for karpatkey is correct.
Can we get the delegates to post their addresses in this thread just to confirm the calldatas for the proposal pls?
@Doo_StableLab @404DAO @rikagoldberg @WintermuteGovernance @PGov @Juanbug @0xkeyrock.eth @kpk @coltron.eth @kfx
StableLab team has made a simple dune dashboard to keep track of Uniswap delegations via Franchiser contract. https://dune.com/queries/3239957
Currently in the dashboard, the address 0xa37131410a76791f4a0210e91edd554d85afb4d4 , which received 2.5 mil UNI in delegation is Uniswap Foundation multisig, which was approved last year.
Confirming 404 DAO's address is correct
My address is correct.
Confirming ours is correct.
Copying from post on competition snapshot poll.
The poll has closed and thanks everyone for voting.
Confirming Top 4 Delegates are 404 DAO, Wintermute Governance, PGov, and StableLab, and will get delegation till 2.5 M is achieved. The rest of UNI (out of 10 M) will be split among Keyrock, Karpatkey, and atiselsts.eth proportional to their votes won.
Nope, has to be called by the owner which is the Timelock in this case - would require a vote.
Thank you for the column. That will indeed be helpful 🙏 I will add it to the excel as well
We just confirmed with qualified delegates their address and shared the draft for the onchain proposal for the feedback.
One area I am a bit stuck on is code with the onchain proposal. A delegate asked me whether the code is ready and simulated. If it's required for the proposal, I am looking for ways to get supported with such.
We just confirmed with qualified delegates their address and shared the draft for the onchain proposal for the feedback.
One area I am a bit stuck on is code with the onchain proposal. A delegate asked me whether the code is ready and simulated. If it's required for the proposal, I am looking for ways to get supported with such.
Once it's ready, we will reach out to delegates who are able to post it onchain for us.
StableLab team has made a simple dune dashboard to keep track of Uniswap delegations via Franchiser contract. https://dune.com/queries/3239957
Currently in the dashboard, the address 0xa37131410a76791f4a0210e91edd554d85afb4d4 , which received 2.5 mil UNI in delegation is Uniswap Foundation multisig, which was approved last year.
Copying from post on competition snapshot poll.
The poll has closed and thanks everyone for voting.
Confirming Top 4 Delegates are 404 DAO, Wintermute Governance, PGov, and StableLab, and will get delegation till 2.5 M is achieved. The rest of UNI (out of 10 M) will be split among Keyrock, Karpatkey, and atiselsts.eth proportional to their votes won.
Next steps would be calculating needed delegation amount for each, and also incorporating technical understanding of the implementation.
Glad to see this moving along!
I added a column in a copy of the sheet to show total votes per delegate if this proposal passes:
Glad to see this moving along!
I added a column in a copy of the sheet to show total votes per delegate if this proposal passes:
| # | Name | Snapshot Votes For | Current Voting Power | Votes Won (UNI) | New Voting Power |
|---|---|---|---|---|---|
| 1 | 404 DAO | 5786355 | 250000 | 2250000 | 2,500,000 |
| 2 | Wintermute Governance | 5643733 | 600000 | 1900000 | 2,500,000 |
| 3 | PGov | 4744613 | 250000 | 2250000 | 2,500,000 |
| 4 | StableLab | 4489610 | 142 | 2499858 | 2,500,000 |
| 5 | Keyrock | 3252294 | 10000 | 493972 | 503,972 |
| 6 | Karpatkey | 2980075 | 467000 | 452626 | 919,626 |
| 7 | atiselsts.eth | 1010931 | 250000 | 153544 | 403,544 |
What are next steps?
Calculation for needed delegation amount for each has been completed.
Calculation method shared here: https://docs.google.com/spreadsheets/d/1XSsipph7GTBMS9hHFWMZxCQVyE0bZhAeADxxIDPKcpg/edit?usp=sharing
Confirming ours is correct as well on the table shared by @Doo_StableLab
I believe this makes sense but will look forward to the community to share their feedback as well. For example, for recall function, can it be also done via offchain voting instead?
Congrats on the snapshot going live. I just wanted to pop in and confirm that my understanding of the on-chain vote that will result is correct.
I believe that it will be one function call on the FranchiserFactory contract here. The Timelock will call the fundMany function, and pass it two arrays of calldata. The first will be [delegatees] and the second will be [amounts]. The address at index 0 of the delegatee array receives the amount of votes at index 0 of the amounts array. The result of that function call will be an individual Franchiser contract deployed for each delegate funded by the amount of tokens defined by this Snapshot.
Congrats on the snapshot going live. I just wanted to pop in and confirm that my understanding of the on-chain vote that will result is correct.
I believe that it will be one function call on the FranchiserFactory contract here. The Timelock will call the fundMany function, and pass it two arrays of calldata. The first will be [delegatees] and the second will be [amounts]. The address at index 0 of the delegatee array receives the amount of votes at index 0 of the amounts array. The result of that function call will be an individual Franchiser contract deployed for each delegate funded by the amount of tokens defined by this Snapshot.
The Timelock will be the owner of all Franchiser contracts deployed from this vote, and can recall the tokens by calling the recall function (via a subsequent on-chain vote) on each contract at any time.
Does this match your understanding of the onchain process @Doo_StableLab?
Separately, it would be great to have a dashboard to track all Franchisers funded by the Timelock... just throwing that out there for the Dune wizards lurking in the forum.
That is correct! I think the snapshot voting should be available today or tomorrow
Confirming 7 delegates @WintermuteGovernance @0xkeyrock.eth @Doo_StableLab @kfx @Juanbug @404DAO @kpk have qualified for the program, but if there's a dispute, please share with the community.
Before proceeding to competition poll (or not depending on the choice), would like to hear the options ahead from both the qualified delegates as well as the community. For this forum poll, the voters are visible, and will take qualified delegates' votes as primary indicator and will take the community's votes as secondary indicator. Please vote by Tuesday but it's optional.
Confirming 7 delegates @WintermuteGovernance @0xkeyrock.eth @Doo_StableLab @kfx @Juanbug @404DAO @kpk have qualified for the program, but if there's a dispute, please share with the community.
Before proceeding to competition poll (or not depending on the choice), would like to hear the options ahead from both the qualified delegates as well as the community. For this forum poll, the voters are visible, and will take qualified delegates' votes as primary indicator and will take the community's votes as secondary indicator. Please vote by Tuesday but it's optional.
[poll type=regular results=always public=true chartType=bar]
We think it’s an interesting idea and it makes sense
The reason I bring the distinction between sponsor and voter up is because 2.5M across 4 entities is too limited in scope (not enough people get UNI), and 1M across 10 is not possible since we don't have enough qualified applicants--plus it doesn't resolve the lack of sponsor issue. A happy medium is taking the 10M UNI, using max 5M of it to upgrade two entities to sponsor level, and the rest can just be voters with a higher delegation amount. I don't think it adds much more complexity to the current proposal.
It's not up to me! But it seems like a reasonable experiment.
I will use Delegate 1234567 as examples.
There will be snapshot voting and let's say at the end of the voting, Delegate 1 got the first place, Delegate 2 got the 2nd place and so on. Delegate 7 getting the last place.
For top 4 delegates that received the most vote, they will receive delegation till each of their delegation reaches 2.5 M UNI.
I will use Delegate 1234567 as examples.
There will be snapshot voting and let's say at the end of the voting, Delegate 1 got the first place, Delegate 2 got the 2nd place and so on. Delegate 7 getting the last place.
For top 4 delegates that received the most vote, they will receive delegation till each of their delegation reaches 2.5 M UNI.
So if Delegate 1 had 0.5 M Uni, Delegate 1 would have 2 M in delegated from this program. If Delegate 2 had 0.1 M Uni, Delegate 2 would have 2.4 M in delegated from this program. The same for Delegate 3 and Delegate 4. And if Delegate 3 and 4 each had 0.2 M UNI, that would mean they each need 2.2 M in delegation.
In total, for top 4, they would have 8.8 M in delegation, which leaves 1.2 M UNI for delegate 5,6, and 7.
For simple example, in voting let's say Delegate 5 got 5 mil in voting, 6 got 3 mil in voting, 7 got 2 mil. so in terms of percentage out of them, Delegate 5 got 50%, 6 got 30%, 7 got 20%.
And they will split 1.2 M UNI delegated based on it so Delegate 5 gets 0.6 M UNI in delegation, Delegate 6 gets 0.36 M UNI, and Delegate 7 gets 0.24 M UNI .
cool yeah i get it now, wasn't clicking for whatever reason.
So next steps are:
right?
Thanks for continuing to push this forward Doo. Can you give me an example of how this will work? I'm not sure i get it.
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.
We decided to put our full voting power behind 404DAO as we’re familiar with their work and activity from our involvement in other protocols and we already have a line of communication with them. We look forward to seeing them more in Uniswap’s governance!
Thanks all for the vote. It was a close vote. However, as
qualified delegates’ votes as primary indicator and will take the community’s votes as secondary indicator.
I like this idea from @AbdullahUmar a lot. Might be a little jenky in practice to put in words, but having the:
Appreciate you @Doo_StableLab for initiating this conversation. Increasing delegate participation and awarding active members with more voting power is important. Here are a couple of comments to consider before the onchain vote:
There are two functions that this proposal should address.
Appreciate you @Doo_StableLab for initiating this conversation. Increasing delegate participation and awarding active members with more voting power is important. Here are a couple of comments to consider before the onchain vote:
There are two functions that this proposal should address.
*All sponsors are voters, but not all voters are sponsors. A voter becomes a sponsor if they have >2.5M UNI, making them eligible for creating an onchain vote.
Sponsors To date, there are very few delegates who can create proposals. Sure, you could ask Uniswap Foundation to lend you some tokens for putting up a particular vote, but I think we need a more autonomous way to facilitate the proposal process long term. Going forward--and a part of this has already been implemented with cross-chain deployment RFCs--it would be nice to add a section to RFCs that acts as a call for potential sponsors to endorse a proposal. If a delegate with >2.5M UNI is very much in support of a proposal, they should reach out to the proposing team to help them facilitate the governance process (and vice versa). We can also add a section to the forums that lists all the relevant sponsors, along with their contact info.
Voters The second aspect, increasing delegates' voting power, is self explanatory in its merits.
This Proposal's Format All this being said, I think we should structure the temp check as "Weighted voting" (each voter may spread voting power across any number of choices). A distinction between sponsor and voter should encourage delegates to give higher weight to candidates that they believe should become sponsors.
The two applicants with the most votes should be allotted an amount of UNI that will make them a sponsor. This would mean that a maximum of ~2.5M UNI can be used to assign two delegate sponsors. The remaining UNI from the 10M total should be evenly distributed among the other candidates (these are the voters). There should be a minimum number of votes, however, that a candidate should receive to be eligible for the mentioned even distribution--we don't want a delegate who attains a very small number of votes to receive the same voting power as one who attains significantly more. This threshold number is something that we collectively determine.
For more visibility, application thread for the delegation of UNI can be found here: https://gov.uniswap.org/t/delegation-of-uni-to-active-but-underrepresented-delegates-application-thread/22265?u=doo_stablelab
The deadline will be November 11th 2023 5PM CET.
We're definitely open to this suggestion as well. More diversity is welcomed while creating something like the CPF would also solve the issue of posting an on-chain vote.
We're open to discuss this on a space as well with all DAO participants.
StableLab team has made a simple dune dashboard to keep track of Uniswap delegations via Franchiser contract. https://dune.com/queries/3239957
Currently in the dashboard, the address 0xa37131410a76791f4a0210e91edd554d85afb4d4 , which received 2.5 mil UNI in delegation is Uniswap Foundation multisig, which was approved last year.
Copying from post on competition snapshot poll.
The poll has closed and thanks everyone for voting.
Confirming Top 4 Delegates are 404 DAO, Wintermute Governance, PGov, and StableLab, and will get delegation till 2.5 M is achieved. The rest of UNI (out of 10 M) will be split among Keyrock, Karpatkey, and atiselsts.eth proportional to their votes won.
Next steps would be calculating needed delegation amount for each, and also incorporating technical understanding of the implementation.
Glad to see this moving along!
I added a column in a copy of the sheet to show total votes per delegate if this proposal passes:
Glad to see this moving along!
I added a column in a copy of the sheet to show total votes per delegate if this proposal passes:
| # | Name | Snapshot Votes For | Current Voting Power | Votes Won (UNI) | New Voting Power |
|---|---|---|---|---|---|
| 1 | 404 DAO | 5786355 | 250000 | 2250000 | 2,500,000 |
| 2 | Wintermute Governance | 5643733 | 600000 | 1900000 | 2,500,000 |
| 3 | PGov | 4744613 | 250000 | 2250000 | 2,500,000 |
| 4 | StableLab | 4489610 | 142 | 2499858 | 2,500,000 |
| 5 | Keyrock | 3252294 | 10000 | 493972 | 503,972 |
| 6 | Karpatkey | 2980075 | 467000 | 452626 | 919,626 |
| 7 | atiselsts.eth | 1010931 | 250000 | 153544 | 403,544 |
What are next steps?
Calculation for needed delegation amount for each has been completed.
Calculation method shared here: https://docs.google.com/spreadsheets/d/1XSsipph7GTBMS9hHFWMZxCQVyE0bZhAeADxxIDPKcpg/edit?usp=sharing
Confirming ours is correct as well on the table shared by @Doo_StableLab
I believe this makes sense but will look forward to the community to share their feedback as well. For example, for recall function, can it be also done via offchain voting instead?
Congrats on the snapshot going live. I just wanted to pop in and confirm that my understanding of the on-chain vote that will result is correct.
I believe that it will be one function call on the FranchiserFactory contract here. The Timelock will call the fundMany function, and pass it two arrays of calldata. The first will be [delegatees] and the second will be [amounts]. The address at index 0 of the delegatee array receives the amount of votes at index 0 of the amounts array. The result of that function call will be an individual Franchiser contract deployed for each delegate funded by the amount of tokens defined by this Snapshot.
Congrats on the snapshot going live. I just wanted to pop in and confirm that my understanding of the on-chain vote that will result is correct.
I believe that it will be one function call on the FranchiserFactory contract here. The Timelock will call the fundMany function, and pass it two arrays of calldata. The first will be [delegatees] and the second will be [amounts]. The address at index 0 of the delegatee array receives the amount of votes at index 0 of the amounts array. The result of that function call will be an individual Franchiser contract deployed for each delegate funded by the amount of tokens defined by this Snapshot.
The Timelock will be the owner of all Franchiser contracts deployed from this vote, and can recall the tokens by calling the recall function (via a subsequent on-chain vote) on each contract at any time.
Does this match your understanding of the onchain process @Doo_StableLab?
Separately, it would be great to have a dashboard to track all Franchisers funded by the Timelock... just throwing that out there for the Dune wizards lurking in the forum.
That is correct! I think the snapshot voting should be available today or tomorrow
Confirming 7 delegates @WintermuteGovernance @0xkeyrock.eth @Doo_StableLab @kfx @Juanbug @404DAO @kpk have qualified for the program, but if there's a dispute, please share with the community.
Before proceeding to competition poll (or not depending on the choice), would like to hear the options ahead from both the qualified delegates as well as the community. For this forum poll, the voters are visible, and will take qualified delegates' votes as primary indicator and will take the community's votes as secondary indicator. Please vote by Tuesday but it's optional.
Confirming 7 delegates @WintermuteGovernance @0xkeyrock.eth @Doo_StableLab @kfx @Juanbug @404DAO @kpk have qualified for the program, but if there's a dispute, please share with the community.
Before proceeding to competition poll (or not depending on the choice), would like to hear the options ahead from both the qualified delegates as well as the community. For this forum poll, the voters are visible, and will take qualified delegates' votes as primary indicator and will take the community's votes as secondary indicator. Please vote by Tuesday but it's optional.
[poll type=regular results=always public=true chartType=bar]
We think it’s an interesting idea and it makes sense
The reason I bring the distinction between sponsor and voter up is because 2.5M across 4 entities is too limited in scope (not enough people get UNI), and 1M across 10 is not possible since we don't have enough qualified applicants--plus it doesn't resolve the lack of sponsor issue. A happy medium is taking the 10M UNI, using max 5M of it to upgrade two entities to sponsor level, and the rest can just be voters with a higher delegation amount. I don't think it adds much more complexity to the current proposal.
It's not up to me! But it seems like a reasonable experiment.
I will use Delegate 1234567 as examples.
There will be snapshot voting and let's say at the end of the voting, Delegate 1 got the first place, Delegate 2 got the 2nd place and so on. Delegate 7 getting the last place.
For top 4 delegates that received the most vote, they will receive delegation till each of their delegation reaches 2.5 M UNI.
I will use Delegate 1234567 as examples.
There will be snapshot voting and let's say at the end of the voting, Delegate 1 got the first place, Delegate 2 got the 2nd place and so on. Delegate 7 getting the last place.
For top 4 delegates that received the most vote, they will receive delegation till each of their delegation reaches 2.5 M UNI.
So if Delegate 1 had 0.5 M Uni, Delegate 1 would have 2 M in delegated from this program. If Delegate 2 had 0.1 M Uni, Delegate 2 would have 2.4 M in delegated from this program. The same for Delegate 3 and Delegate 4. And if Delegate 3 and 4 each had 0.2 M UNI, that would mean they each need 2.2 M in delegation.
In total, for top 4, they would have 8.8 M in delegation, which leaves 1.2 M UNI for delegate 5,6, and 7.
For simple example, in voting let's say Delegate 5 got 5 mil in voting, 6 got 3 mil in voting, 7 got 2 mil. so in terms of percentage out of them, Delegate 5 got 50%, 6 got 30%, 7 got 20%.
And they will split 1.2 M UNI delegated based on it so Delegate 5 gets 0.6 M UNI in delegation, Delegate 6 gets 0.36 M UNI, and Delegate 7 gets 0.24 M UNI .
cool yeah i get it now, wasn't clicking for whatever reason.
So next steps are:
right?
Thanks for continuing to push this forward Doo. Can you give me an example of how this will work? I'm not sure i get it.
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.
We decided to put our full voting power behind 404DAO as we’re familiar with their work and activity from our involvement in other protocols and we already have a line of communication with them. We look forward to seeing them more in Uniswap’s governance!
Thanks all for the vote. It was a close vote. However, as
qualified delegates’ votes as primary indicator and will take the community’s votes as secondary indicator.
I like this idea from @AbdullahUmar a lot. Might be a little jenky in practice to put in words, but having the:
Appreciate you @Doo_StableLab for initiating this conversation. Increasing delegate participation and awarding active members with more voting power is important. Here are a couple of comments to consider before the onchain vote:
There are two functions that this proposal should address.
Appreciate you @Doo_StableLab for initiating this conversation. Increasing delegate participation and awarding active members with more voting power is important. Here are a couple of comments to consider before the onchain vote:
There are two functions that this proposal should address.
*All sponsors are voters, but not all voters are sponsors. A voter becomes a sponsor if they have >2.5M UNI, making them eligible for creating an onchain vote.
Sponsors To date, there are very few delegates who can create proposals. Sure, you could ask Uniswap Foundation to lend you some tokens for putting up a particular vote, but I think we need a more autonomous way to facilitate the proposal process long term. Going forward--and a part of this has already been implemented with cross-chain deployment RFCs--it would be nice to add a section to RFCs that acts as a call for potential sponsors to endorse a proposal. If a delegate with >2.5M UNI is very much in support of a proposal, they should reach out to the proposing team to help them facilitate the governance process (and vice versa). We can also add a section to the forums that lists all the relevant sponsors, along with their contact info.
Voters The second aspect, increasing delegates' voting power, is self explanatory in its merits.
This Proposal's Format All this being said, I think we should structure the temp check as "Weighted voting" (each voter may spread voting power across any number of choices). A distinction between sponsor and voter should encourage delegates to give higher weight to candidates that they believe should become sponsors.
The two applicants with the most votes should be allotted an amount of UNI that will make them a sponsor. This would mean that a maximum of ~2.5M UNI can be used to assign two delegate sponsors. The remaining UNI from the 10M total should be evenly distributed among the other candidates (these are the voters). There should be a minimum number of votes, however, that a candidate should receive to be eligible for the mentioned even distribution--we don't want a delegate who attains a very small number of votes to receive the same voting power as one who attains significantly more. This threshold number is something that we collectively determine.
For more visibility, application thread for the delegation of UNI can be found here: https://gov.uniswap.org/t/delegation-of-uni-to-active-but-underrepresented-delegates-application-thread/22265?u=doo_stablelab
The deadline will be November 11th 2023 5PM CET.
We're definitely open to this suggestion as well. More diversity is welcomed while creating something like the CPF would also solve the issue of posting an on-chain vote.
We're open to discuss this on a space as well with all DAO participants.
Thanks all for the vote. It was a close vote. However, as
qualified delegates’ votes as primary indicator and will take the community’s votes as secondary indicator.
Two qualified delegates voted for "Split Equally" while four qualified delegates voted for "top 4 Delegates get delegation till 2.5 Mil". Therefore, will be proceed with snapshot vote reflecting "Top 4 Delegates get delegation till 2.5 M is achieved. the rest of UNI are split among the rest proportional to their votes won."
Thank you!
There are two more days to go but currently there are 5 qualified applicants and unlikely to have 10 qualified delegates apply. However, instead of lowering the requirement or extending the process, I was thinking maybe we can have it 10 mil UNI divided by qualified applicants by the deadline.
So for example, if there are 5 by the end of the deadline, it would be 2mil UNI delegated each, which would allow Wintermute to post onchain votes but for others would still be below the threshold. If there are 6 or more, all would be below the threshhold.
As the point of this program is accountability, it will be easier for the community to track of smaller number of delegates.
Actually I re-read @AbdullahUmar 's point and seems like I misunderstood it. It might be interesting and I think it's really the question for @eek637, whether it would be ok to add 2-3 additional delegates in the governance ecosystem who would be able to make onchain proposals
Where are the 10M UNI that will be delegated coming from?
It will come from the treasury.
It will come from the treasury.
Just looking at 90% participation rate, there were 10 delegates or so that meet the participation requirement. Since this has been lowered to 80%, there will be many more who qualify.
Also, we’d like to suggest that there’s an update from the delegates in 6 months to avoid having to wait a full year for the delegation to expire in case there are reasons to end it before that time.
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.
We appreciate the proposal and we’ll be voting in favour of it as we are supportive of initiatives aiming to increase meaningful participation in governance.
We’re curious to know though:
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.
We appreciate the proposal and we’ll be voting in favour of it as we are supportive of initiatives aiming to increase meaningful participation in governance.
We’re curious to know though:
Also, we’d like to suggest that there’s an update from the delegates in 6 months to avoid having to wait a full year for the delegation to expire in case there are reasons to end it before that time.
Thanks for the suggestion. That would be an interesting mechanism as the focus on 2.5 mil was mainly aimed toward to solve the issue of who could post a vote as you mentioned. As the application period will end by this weekend, we can hold off on moving to another snapshot (as originally, if more than 4, the proposal wanted to have a snapshot to choose top 4), and have a space to discuss with the applicants together to talk about the options.
Diversifying the number of entities that can sponsor an onchain proposal (Sponsors)
Diversifying the number of entities that can sponsor an onchain proposal (Sponsors)
I appreciate the initiative as well as suggestions from @Juanbug as well. But for those, I would rather have it as separate proposal (which can run in parallel) because of practical reason that from experience , the more moving parts the proposal has, the longer it will take to get all the details.
I'm watching the delegate nominations come in and they are all good options. This led me to think about how we might tweak the parameters suggested here. What if, instead of delegating 2.5m UNI to 4 delegates, we delegate 1m UNI to 10 delegates? This would of course would mean that we hadn't changed the dynamics of who could post a vote. So I would also recommend that we proceed with this proposal from @GFXlabs.
The result would be a larger number of delegates with a meaningful (albeit smaller) increase in voting power, as well as increased access to on-chain proposal power.
I'm watching the delegate nominations come in and they are all good options. This led me to think about how we might tweak the parameters suggested here. What if, instead of delegating 2.5m UNI to 4 delegates, we delegate 1m UNI to 10 delegates? This would of course would mean that we hadn't changed the dynamics of who could post a vote. So I would also recommend that we proceed with this proposal from @GFXlabs.
The result would be a larger number of delegates with a meaningful (albeit smaller) increase in voting power, as well as increased access to on-chain proposal power.
Would join a spaces to talk about this at some point if anyone's interested?
Thanks all for the vote. It was a close vote. However, as
qualified delegates’ votes as primary indicator and will take the community’s votes as secondary indicator.
Two qualified delegates voted for "Split Equally" while four qualified delegates voted for "top 4 Delegates get delegation till 2.5 Mil". Therefore, will be proceed with snapshot vote reflecting "Top 4 Delegates get delegation till 2.5 M is achieved. the rest of UNI are split among the rest proportional to their votes won."
Thank you!
There are two more days to go but currently there are 5 qualified applicants and unlikely to have 10 qualified delegates apply. However, instead of lowering the requirement or extending the process, I was thinking maybe we can have it 10 mil UNI divided by qualified applicants by the deadline.
So for example, if there are 5 by the end of the deadline, it would be 2mil UNI delegated each, which would allow Wintermute to post onchain votes but for others would still be below the threshold. If there are 6 or more, all would be below the threshhold.
As the point of this program is accountability, it will be easier for the community to track of smaller number of delegates.
Actually I re-read @AbdullahUmar 's point and seems like I misunderstood it. It might be interesting and I think it's really the question for @eek637, whether it would be ok to add 2-3 additional delegates in the governance ecosystem who would be able to make onchain proposals
Where are the 10M UNI that will be delegated coming from?
It will come from the treasury.
It will come from the treasury.
Just looking at 90% participation rate, there were 10 delegates or so that meet the participation requirement. Since this has been lowered to 80%, there will be many more who qualify.
Also, we’d like to suggest that there’s an update from the delegates in 6 months to avoid having to wait a full year for the delegation to expire in case there are reasons to end it before that time.
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.
We appreciate the proposal and we’ll be voting in favour of it as we are supportive of initiatives aiming to increase meaningful participation in governance.
We’re curious to know though:
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.
We appreciate the proposal and we’ll be voting in favour of it as we are supportive of initiatives aiming to increase meaningful participation in governance.
We’re curious to know though:
Also, we’d like to suggest that there’s an update from the delegates in 6 months to avoid having to wait a full year for the delegation to expire in case there are reasons to end it before that time.
Thanks for the suggestion. That would be an interesting mechanism as the focus on 2.5 mil was mainly aimed toward to solve the issue of who could post a vote as you mentioned. As the application period will end by this weekend, we can hold off on moving to another snapshot (as originally, if more than 4, the proposal wanted to have a snapshot to choose top 4), and have a space to discuss with the applicants together to talk about the options.
Diversifying the number of entities that can sponsor an onchain proposal (Sponsors)
Diversifying the number of entities that can sponsor an onchain proposal (Sponsors)
I appreciate the initiative as well as suggestions from @Juanbug as well. But for those, I would rather have it as separate proposal (which can run in parallel) because of practical reason that from experience , the more moving parts the proposal has, the longer it will take to get all the details.
I'm watching the delegate nominations come in and they are all good options. This led me to think about how we might tweak the parameters suggested here. What if, instead of delegating 2.5m UNI to 4 delegates, we delegate 1m UNI to 10 delegates? This would of course would mean that we hadn't changed the dynamics of who could post a vote. So I would also recommend that we proceed with this proposal from @GFXlabs.
The result would be a larger number of delegates with a meaningful (albeit smaller) increase in voting power, as well as increased access to on-chain proposal power.
I'm watching the delegate nominations come in and they are all good options. This led me to think about how we might tweak the parameters suggested here. What if, instead of delegating 2.5m UNI to 4 delegates, we delegate 1m UNI to 10 delegates? This would of course would mean that we hadn't changed the dynamics of who could post a vote. So I would also recommend that we proceed with this proposal from @GFXlabs.
The result would be a larger number of delegates with a meaningful (albeit smaller) increase in voting power, as well as increased access to on-chain proposal power.
Would join a spaces to talk about this at some point if anyone's interested?
