Authors: MichiganBlockchain, @404DAO, @GFXlabs
TL;DR: Introduce an amendment to the Uniswap V3 Factory owner to allow the DAO to make future changes to the fee mechanism. This will prevent the DAO from being pigeonholed by a singular, immutable implementation, thereby enabling further experimentation and allowing the DAO to effectively respond to issues with the current setup.
To not significantly slow down the current process proposed by the Foundation, this Snapshot poll will be used to collect opinions via a vote from the delegates. There will be two options, “Accept amendment” or “Reject amendment.” If the “Accept amendment” is able to demonstrate a significant majority, then we would expect the onchain proposal put forth by the Foundation to include the change. The poll will go up immediately and end on March 8th.
Authors: MichiganBlockchain, @404DAO, @GFXlabs
TL;DR: Introduce an amendment to the Uniswap V3 Factory owner to allow the DAO to make future changes to the fee mechanism. This will prevent the DAO from being pigeonholed by a singular, immutable implementation, thereby enabling further experimentation and allowing the DAO to effectively respond to issues with the current setup.
To not significantly slow down the current process proposed by the Foundation, this Snapshot poll will be used to collect opinions via a vote from the delegates. There will be two options, “Accept amendment” or “Reject amendment.” If the “Accept amendment” is able to demonstrate a significant majority, then we would expect the onchain proposal put forth by the Foundation to include the change. The poll will go up immediately and end on March 8th.
https://gov.uniswap.org/t/uniswap-v3-fees-factory-owner-amendment/23187/14?u=kaereste
https://gov.uniswap.org/t/uniswap-v3-fees-factory-owner-amendment/23187/14?u=kaereste
Having the flexibility to modify the fee mechanism through a mutable contract guards against unintended consequences
Having the flexibility to modify the fee mechanism through a mutable contract guards against unintended consequences
any update ? fee switch activation topics seem stuck
any update ? fee switch activation topics seem stuck
We are excited to see that the Activating Uniswap Governance proposal brought forth by the Uniswap Foundation has definitively passed on snapshot. The proposal marks an exciting new chapter in Uniswap governance. With the setOwner() amendment snapshot still ongoing, we would like to clarify that the primary intention of the vote is to gather the opinions of other delegates and provide a signal of overall sentiment. If this vote were to pass, we do not intend to immediately proceed with an onchain vote and will wait until greater consensus is achieved among all stakeholders.
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.
After reading the original proposal the amendment refers to, as well as the discussion below this proposal, we’ve decided we’ll be voting against the factory owner amendment. We believe there’s a middle ground to be reached that allows for flexibility without compromising on security, as suggested by @eek637 in the original proposal.
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.
After reading the original proposal the amendment refers to, as well as the discussion below this proposal, we’ve decided we’ll be voting against the factory owner amendment. We believe there’s a middle ground to be reached that allows for flexibility without compromising on security, as suggested by @eek637 in the original proposal.
So far, the main argument we’ve seen against activating the protocol’s governance is that we should discuss the implementation more, without offering any concrete counterarguments against the currently proposed one. As we don’t feel convinced that this amendment should be enforced, we are voting against it.
but gives the DAO the ability to improve by changing the protocol fees and adding fee tiers.
We are (and I specifically am) opposed to this amendment. Having spent months designing this system, we believe that the current implementation provides most of the benefits described above while maintaining the credible neutrality that is a core tenet of Uniswap’s value proposition and minimizing the technical risk presented by future V3FactoryOwner or UniStaker upgrades.
UniStaker can be used as a building block for new incentive models in a risk-mitigated way. Contracts can be built on top of it and funded with treasury UNI to steer votes and rewards to novel incentive protocols. In the case where there are multiple of these incentive protocols running at the same time, each could be spun up or down by a governance vote without impacting the audit surface area of the core system contracts (which in my mind are the contracts that allow protocol fee collection, conversion, and distribution). This is not the case if these experiments were to be run using setOwner(). In that case, the entire system (V3FactoryOwner and UniStaker) would need to be re-written, re-audited, and re-deployed. Our system actually enables easier experimentation.
then we would expect the onchain proposal put forth by the Foundation to include the change.
Apology as I was not able to attend ETHDenver but from the context I am reading, is it correct that that's what the Foundation also agreed on? That if there's voting to change it and it passes, then it will be changed?
After a few days of very productive discussion at GovSwap, we are in fill support of this. For now, being how new and bombshell this announcement has been, we want to ensure proper time to make sure it is able to be updated in case it’s needed while still getting these amazing new developments shipped and running!
To not significantly slow down the current process proposed by the Foundation, a Snapshot poll will be used to collect opinions via a vote from the delegates. There will be two options, “Accept amendment” or “Reject amendment.” If the “Accept amendment” is able to demonstrate a significant majority, then we would expect the onchain proposal put forth by the Foundation to include the change. The poll will go up immediately and end on March 8th.
Lastly, we would like to reiterate our general support for the proposed mechanism and our appreciation for the Uniswap Foundation’s efforts to bring this proposal to the DAO.
The poll is live: link
Thank you for the post. We appreciate the perspective.
Interesting idea. If you could elaborate on it, how would that map to the DAOs ability to turn on fees for other versions of the protocol? If you could generally expand on your point, that would be helpful.
The proposed amendment cannot affect/remove token holders' staked UNI or other protocol positions. We, GFX, agree it can redirect/fee revenue to UNI stakeholders. If delegates someday wish to use the proposed function they should, as we would, closely consider the existing stakers and built staking infrastructure. We have faith in delegates to manage that responsibility.
You are absolutely right that immutability is a core feature of Uniswap. Something we have always appreciated about the Uniswap protocol is that, unlike many protocols, Uniswap governance cannot put user funds at risk but gives the DAO the ability to improve by changing the protocol fees and adding fee tiers. This amendment builds on that by ensuring UNI stakers do not entrust their UNI to the protocol's governance. Still, the amendment allows the DAO to improve upon the mechanism. We feel this is the appropriate decision.
Thank you for posts on both sides. We are thinking maybe there's a way to solve these issues without amending Uniswap V3 Factory owner
Thank you for posts on both sides. We are thinking maybe there's a way to solve these issues without amending Uniswap V3 Factory owner
There can be some brain storming and discussion, but for example, if the issue is economic incentive for delegators to delegate to inactive or burner address. Maybe there can be separate budget to reward delegators who act in good faith. Sure, there will be still ones that do delegate to inactive or buner address but those who are motivated would switch over to act in good faith
We are excited to see that the Activating Uniswap Governance proposal brought forth by the Uniswap Foundation has definitively passed on snapshot. The proposal marks an exciting new chapter in Uniswap governance. With the setOwner() amendment snapshot still ongoing, we would like to clarify that the primary intention of the vote is to gather the opinions of other delegates and provide a signal of overall sentiment. If this vote were to pass, we do not intend to immediately proceed with an onchain vote and will wait until greater consensus is achieved among all stakeholders.
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.
After reading the original proposal the amendment refers to, as well as the discussion below this proposal, we’ve decided we’ll be voting against the factory owner amendment. We believe there’s a middle ground to be reached that allows for flexibility without compromising on security, as suggested by @eek637 in the original proposal.
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.
After reading the original proposal the amendment refers to, as well as the discussion below this proposal, we’ve decided we’ll be voting against the factory owner amendment. We believe there’s a middle ground to be reached that allows for flexibility without compromising on security, as suggested by @eek637 in the original proposal.
So far, the main argument we’ve seen against activating the protocol’s governance is that we should discuss the implementation more, without offering any concrete counterarguments against the currently proposed one. As we don’t feel convinced that this amendment should be enforced, we are voting against it.
but gives the DAO the ability to improve by changing the protocol fees and adding fee tiers.
We are (and I specifically am) opposed to this amendment. Having spent months designing this system, we believe that the current implementation provides most of the benefits described above while maintaining the credible neutrality that is a core tenet of Uniswap’s value proposition and minimizing the technical risk presented by future V3FactoryOwner or UniStaker upgrades.
UniStaker can be used as a building block for new incentive models in a risk-mitigated way. Contracts can be built on top of it and funded with treasury UNI to steer votes and rewards to novel incentive protocols. In the case where there are multiple of these incentive protocols running at the same time, each could be spun up or down by a governance vote without impacting the audit surface area of the core system contracts (which in my mind are the contracts that allow protocol fee collection, conversion, and distribution). This is not the case if these experiments were to be run using setOwner(). In that case, the entire system (V3FactoryOwner and UniStaker) would need to be re-written, re-audited, and re-deployed. Our system actually enables easier experimentation.
then we would expect the onchain proposal put forth by the Foundation to include the change.
Apology as I was not able to attend ETHDenver but from the context I am reading, is it correct that that's what the Foundation also agreed on? That if there's voting to change it and it passes, then it will be changed?
After a few days of very productive discussion at GovSwap, we are in fill support of this. For now, being how new and bombshell this announcement has been, we want to ensure proper time to make sure it is able to be updated in case it’s needed while still getting these amazing new developments shipped and running!
To not significantly slow down the current process proposed by the Foundation, a Snapshot poll will be used to collect opinions via a vote from the delegates. There will be two options, “Accept amendment” or “Reject amendment.” If the “Accept amendment” is able to demonstrate a significant majority, then we would expect the onchain proposal put forth by the Foundation to include the change. The poll will go up immediately and end on March 8th.
Lastly, we would like to reiterate our general support for the proposed mechanism and our appreciation for the Uniswap Foundation’s efforts to bring this proposal to the DAO.
The poll is live: link
Thank you for the post. We appreciate the perspective.
Interesting idea. If you could elaborate on it, how would that map to the DAOs ability to turn on fees for other versions of the protocol? If you could generally expand on your point, that would be helpful.
The proposed amendment cannot affect/remove token holders' staked UNI or other protocol positions. We, GFX, agree it can redirect/fee revenue to UNI stakeholders. If delegates someday wish to use the proposed function they should, as we would, closely consider the existing stakers and built staking infrastructure. We have faith in delegates to manage that responsibility.
You are absolutely right that immutability is a core feature of Uniswap. Something we have always appreciated about the Uniswap protocol is that, unlike many protocols, Uniswap governance cannot put user funds at risk but gives the DAO the ability to improve by changing the protocol fees and adding fee tiers. This amendment builds on that by ensuring UNI stakers do not entrust their UNI to the protocol's governance. Still, the amendment allows the DAO to improve upon the mechanism. We feel this is the appropriate decision.
Thank you for posts on both sides. We are thinking maybe there's a way to solve these issues without amending Uniswap V3 Factory owner
Thank you for posts on both sides. We are thinking maybe there's a way to solve these issues without amending Uniswap V3 Factory owner
There can be some brain storming and discussion, but for example, if the issue is economic incentive for delegators to delegate to inactive or burner address. Maybe there can be separate budget to reward delegators who act in good faith. Sure, there will be still ones that do delegate to inactive or buner address but those who are motivated would switch over to act in good faith
but gives the DAO the ability to improve by changing the protocol fees and adding fee tiers.
This is a disengenous comparison. Changes that can be made by governance in the case of the AMM are bounded to these two things. Liquidity providers can easily reason about the universe of potential changes, because there are two of them. The upgrade you are suggesting allows for unbounded system design changes.
We are (and I specifically am) opposed to this amendment. Having spent months designing this system, we believe that the current implementation provides most of the benefits described above while maintaining the credible neutrality that is a core tenet of Uniswap’s value proposition and minimizing the technical risk presented by future V3FactoryOwner or UniStaker upgrades.
UniStaker can be used as a building block for new incentive models in a risk-mitigated way. Contracts can be built on top of it and funded with treasury UNI to steer votes and rewards to novel incentive protocols. In the case where there are multiple of these incentive protocols running at the same time, each could be spun up or down by a governance vote without impacting the audit surface area of the core system contracts (which in my mind are the contracts that allow protocol fee collection, conversion, and distribution). This is not the case if these experiments were to be run using setOwner(). In that case, the entire system (V3FactoryOwner and UniStaker) would need to be re-written, re-audited, and re-deployed. Our system actually enables easier experimentation.
If we were to adopt this amendment, each time that base-level contract infrastructure changed it would present technical and implementation risk that is not negligible. And it’s not a “lack of trust in governance” that leads me to this belief, it’s looking at a long history of very sharp teams writing and implementing upgrades and subsequently being hacked (i.e., Nomad). A V3FactoryOwner or UniStaker that rewarded multiple stakeholders in different ways would have a necessarily complex internal accounting system. Each time one aspect of this system changed (say, gas rebates for swappers) the others would be at risk.
Finally, as Leighton points out, the ability to change these contracts introduces rug risk for token holders and ecosystem builders. Uniswap has historically shipped immutable smart contracts to prioritize user safety and credible neutrality. If those are values we want to move away from, that’s a conversation we can have, but we should be very open about the fact that it is a departure. I do not personally want to move away from those values, because I believe they will be what drive our long term success.
We at Stanford Blockchain are very happy to see and support this amendment. Having the flexibility to modify the fee mechanism through a mutable V3FactoryOwner.sol increases the amount of guardrails available in case of exploitation and unintended consequences.
Perhaps the original intention was to prevent the possibility of exploitation by DAO delegates, which I think is a valid concern. Just because it hasn't happened yet doesn't mean its impossible, esp. if financial incentives become sufficiently strong post fee-switch. To address this problem though, I would prefer to see an extra "checks and balance" mechanism, such as an LP veto, rather than full immutability of the contract.
I don't think the cost are worth the meaningful benefits here. My logic is as follows:
Implementing this change opens up the argument that all UNI token holders technically have control over the flow of funds. If UNI token holders can vote at any time to change how these funds flow then arguably for tax purposes this is income and they could attempt to hold any individual holder liable for it. This argument hasn't been fully tested out in the legislature / courts yet and this single fact wouldn't make or break the analysis but I think it is wise to be more conservative here.
As the authors noted, upgradeable contracts introduce the ability for governance to rug token holders / ecosystem builders. It will be hard for this system to get traction if it can be changed.
Uniswap specifically has always held immutability as a core value. Yes, there are meaningful tradeoffs but people expect the Uniswap protocol to be something they can rely on with enshrined rules.
I don't think the cost are worth the meaningful benefits here. My logic is as follows:
Implementing this change opens up the argument that all UNI token holders technically have control over the flow of funds. If UNI token holders can vote at any time to change how these funds flow then arguably for tax purposes this is income and they could attempt to hold any individual holder liable for it. This argument hasn't been fully tested out in the legislature / courts yet and this single fact wouldn't make or break the analysis but I think it is wise to be more conservative here.
As the authors noted, upgradeable contracts introduce the ability for governance to rug token holders / ecosystem builders. It will be hard for this system to get traction if it can be changed.
Uniswap specifically has always held immutability as a core value. Yes, there are meaningful tradeoffs but people expect the Uniswap protocol to be something they can rely on with enshrined rules.
For these reasons I favor keeping this immutable. I do understand there are real benefits ot the upgradeability but I don't think worth the cost.
We’re excited to share this amendment in collaboration with @GFXLabs and MichiganBlockchain and believe that it will help strengthen Uniswap Governance for the long term. It is clear that the Foundation put significant thought into making its decisions for the Activate Uniswap Protocol Governance proposal and we’d like to again echo our appreciation for their hard work. We look forward to hearing additional comments from the Foundation as well as the opinions of other delegates on this proposed amendment.
Thanks Erin for following up here.
Our hope is that we don’t have to go through numerous iterations where a new architecture has to be designed and audited, etc. This, as you correctly state, is an arduous process. What we’re hoping for is optionality. Having the setOwner() function present means that IF the DAO deems the current setup to be ineffective, and if the experimentation you’re suggesting with UniStaker is not to the liking of the DAO/token holders, then we have the ability to remodel. By no means should we be continually altering the present setup. We can test how well UniStaker functions and MAYBE change it later on.
Thanks Erin for following up here.
Our hope is that we don’t have to go through numerous iterations where a new architecture has to be designed and audited, etc. This, as you correctly state, is an arduous process. What we’re hoping for is optionality. Having the setOwner() function present means that IF the DAO deems the current setup to be ineffective, and if the experimentation you’re suggesting with UniStaker is not to the liking of the DAO/token holders, then we have the ability to remodel. By no means should we be continually altering the present setup. We can test how well UniStaker functions and MAYBE change it later on.
For example, the following method may work--
Contracts can be built on top of it and funded with treasury UNI to steer votes and rewards to novel incentive protocols
Sure, there will be still ones that do delegate to inactive or buner address but those who are motivated would switch over to act in good faith
^If all goes well, then later on we could opt for removing the setOwner(). The question is--how optimistic do we want to be? We're just proposing for there to be a backstop which could later be removed as we collect empirical data on how the system actually works.
To the point of credible neutrality--designing a protocol at its core layer should ideally be credibly neutral. However, token holders and delegates should later on be able to decide how credibly neutral they want to be with the fee collection/distribution mechanism. Credible neutrality isn't necessarily the best option if collectively the group wants to make a more biased decision. It's all about have a neutral base layer and then introducing potential avenues of bias later on to better address the needs/wants of the stakeholders.
It may also be worth doing a survey of large token holders to see if having the ability to alter the system deters them from staking their $UNI in the first place.
but gives the DAO the ability to improve by changing the protocol fees and adding fee tiers.
This is a disengenous comparison. Changes that can be made by governance in the case of the AMM are bounded to these two things. Liquidity providers can easily reason about the universe of potential changes, because there are two of them. The upgrade you are suggesting allows for unbounded system design changes.
We are (and I specifically am) opposed to this amendment. Having spent months designing this system, we believe that the current implementation provides most of the benefits described above while maintaining the credible neutrality that is a core tenet of Uniswap’s value proposition and minimizing the technical risk presented by future V3FactoryOwner or UniStaker upgrades.
UniStaker can be used as a building block for new incentive models in a risk-mitigated way. Contracts can be built on top of it and funded with treasury UNI to steer votes and rewards to novel incentive protocols. In the case where there are multiple of these incentive protocols running at the same time, each could be spun up or down by a governance vote without impacting the audit surface area of the core system contracts (which in my mind are the contracts that allow protocol fee collection, conversion, and distribution). This is not the case if these experiments were to be run using setOwner(). In that case, the entire system (V3FactoryOwner and UniStaker) would need to be re-written, re-audited, and re-deployed. Our system actually enables easier experimentation.
If we were to adopt this amendment, each time that base-level contract infrastructure changed it would present technical and implementation risk that is not negligible. And it’s not a “lack of trust in governance” that leads me to this belief, it’s looking at a long history of very sharp teams writing and implementing upgrades and subsequently being hacked (i.e., Nomad). A V3FactoryOwner or UniStaker that rewarded multiple stakeholders in different ways would have a necessarily complex internal accounting system. Each time one aspect of this system changed (say, gas rebates for swappers) the others would be at risk.
Finally, as Leighton points out, the ability to change these contracts introduces rug risk for token holders and ecosystem builders. Uniswap has historically shipped immutable smart contracts to prioritize user safety and credible neutrality. If those are values we want to move away from, that’s a conversation we can have, but we should be very open about the fact that it is a departure. I do not personally want to move away from those values, because I believe they will be what drive our long term success.
We at Stanford Blockchain are very happy to see and support this amendment. Having the flexibility to modify the fee mechanism through a mutable V3FactoryOwner.sol increases the amount of guardrails available in case of exploitation and unintended consequences.
Perhaps the original intention was to prevent the possibility of exploitation by DAO delegates, which I think is a valid concern. Just because it hasn't happened yet doesn't mean its impossible, esp. if financial incentives become sufficiently strong post fee-switch. To address this problem though, I would prefer to see an extra "checks and balance" mechanism, such as an LP veto, rather than full immutability of the contract.
I don't think the cost are worth the meaningful benefits here. My logic is as follows:
Implementing this change opens up the argument that all UNI token holders technically have control over the flow of funds. If UNI token holders can vote at any time to change how these funds flow then arguably for tax purposes this is income and they could attempt to hold any individual holder liable for it. This argument hasn't been fully tested out in the legislature / courts yet and this single fact wouldn't make or break the analysis but I think it is wise to be more conservative here.
As the authors noted, upgradeable contracts introduce the ability for governance to rug token holders / ecosystem builders. It will be hard for this system to get traction if it can be changed.
Uniswap specifically has always held immutability as a core value. Yes, there are meaningful tradeoffs but people expect the Uniswap protocol to be something they can rely on with enshrined rules.
I don't think the cost are worth the meaningful benefits here. My logic is as follows:
Implementing this change opens up the argument that all UNI token holders technically have control over the flow of funds. If UNI token holders can vote at any time to change how these funds flow then arguably for tax purposes this is income and they could attempt to hold any individual holder liable for it. This argument hasn't been fully tested out in the legislature / courts yet and this single fact wouldn't make or break the analysis but I think it is wise to be more conservative here.
As the authors noted, upgradeable contracts introduce the ability for governance to rug token holders / ecosystem builders. It will be hard for this system to get traction if it can be changed.
Uniswap specifically has always held immutability as a core value. Yes, there are meaningful tradeoffs but people expect the Uniswap protocol to be something they can rely on with enshrined rules.
For these reasons I favor keeping this immutable. I do understand there are real benefits ot the upgradeability but I don't think worth the cost.
We’re excited to share this amendment in collaboration with @GFXLabs and MichiganBlockchain and believe that it will help strengthen Uniswap Governance for the long term. It is clear that the Foundation put significant thought into making its decisions for the Activate Uniswap Protocol Governance proposal and we’d like to again echo our appreciation for their hard work. We look forward to hearing additional comments from the Foundation as well as the opinions of other delegates on this proposed amendment.
Thanks Erin for following up here.
Our hope is that we don’t have to go through numerous iterations where a new architecture has to be designed and audited, etc. This, as you correctly state, is an arduous process. What we’re hoping for is optionality. Having the setOwner() function present means that IF the DAO deems the current setup to be ineffective, and if the experimentation you’re suggesting with UniStaker is not to the liking of the DAO/token holders, then we have the ability to remodel. By no means should we be continually altering the present setup. We can test how well UniStaker functions and MAYBE change it later on.
Thanks Erin for following up here.
Our hope is that we don’t have to go through numerous iterations where a new architecture has to be designed and audited, etc. This, as you correctly state, is an arduous process. What we’re hoping for is optionality. Having the setOwner() function present means that IF the DAO deems the current setup to be ineffective, and if the experimentation you’re suggesting with UniStaker is not to the liking of the DAO/token holders, then we have the ability to remodel. By no means should we be continually altering the present setup. We can test how well UniStaker functions and MAYBE change it later on.
For example, the following method may work--
Contracts can be built on top of it and funded with treasury UNI to steer votes and rewards to novel incentive protocols
Sure, there will be still ones that do delegate to inactive or buner address but those who are motivated would switch over to act in good faith
^If all goes well, then later on we could opt for removing the setOwner(). The question is--how optimistic do we want to be? We're just proposing for there to be a backstop which could later be removed as we collect empirical data on how the system actually works.
To the point of credible neutrality--designing a protocol at its core layer should ideally be credibly neutral. However, token holders and delegates should later on be able to decide how credibly neutral they want to be with the fee collection/distribution mechanism. Credible neutrality isn't necessarily the best option if collectively the group wants to make a more biased decision. It's all about have a neutral base layer and then introducing potential avenues of bias later on to better address the needs/wants of the stakeholders.
It may also be worth doing a survey of large token holders to see if having the ability to alter the system deters them from staking their $UNI in the first place.
