Uniswap V3 Fees: Factory Owner Amendment

Governance-Meta
1

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.

Introduction

We appreciate the Uniswap Foundation’s effort on the protocol fee proposal and look forward to supporting the proposal at the onchain vote. Overall, the implementation proposed is well thought out and provides a strong foundation for the execution of a fee switch to strengthen Uniswap and its governance.

However, in the current proposal, the V3FactoryOwner.sol does not have a function to set a new owner to UniswapV3Factory.sol, making this a permanent change to the protocol. This is akin to locking a door and throwing away the key. If the proposal is approved, it will be impossible for anyone to alter the V3FactoryOwner.sol, which we believe is overly constrictive. Despite extensive analysis from several parties, it’s still unknown how activated protocol fees and this new governance mechanism will impact the protocol once implemented–and assuming that the DAO gets the implementation right the first time around is too optimistic. Hence, opting for full immutability stifles experimentation.

Since Uniswap V3 was launched 3 years ago, the DAO has had the power to use the setOwner() function of the UniswapV3Factory.sol contract. This capability has never been exploited, abused, or even used by governance or any bad actor. In addition, the DAO has shown its ability to steward the protocol over the course of the +40 proposals since V3’s deployment.

This proposed amendment, if passed, will add a setOwner() function to the V3FactoryOwner.sol contract. In the case that delegates wish to transition to a new system due to the potential ineffectiveness of the current system, a setOwner() function is necessary to include in the V3FactoryOwner.sol contract, just as it is necessary to make the currently proposed upgrade by the Uniswap Foundation.

Adding the setOwner() function would allow governance to make amendments to the current implementation. Removing this ability inhibits the jurisdiction of the DAO and partially signals a lack of trust in governance. The introduction of the setOwner() function requires very little code and will allow the DAO to prudently respond to any potential limitations that arise with the current implementation.

Reasoning

The goal of the Foundation’s proposal is twofold:

  1. To make the DAO more robust by engaging more circulating $UNI in governance
  2. Create an economic incentive for $UNI holders to delegate their $UNI

This amendment better accomplishes the above goals. Let’s break down why.

We Don’t Know If the Current Design is Best for the Token Holders and the DAO

@WintermuteGovernance put it well:

Immutability has its benefits, but it doesn’t come without a cost. Note, we are not addressing the nature of the core protocol smart contracts or staking contracts–those are indeed immutable. This proposal is about the contracts related to Uniswap v3 fees. Such an area is nascent and lacks experimentation. The DAO and the Foundation are responsible for ensuring token holders and delegates are properly compensated under a fair fee collection and distribution system. Immutability hinders this experimentation and fetters v3 to an untested fee design…forever.

To operationalize this concern, let’s turn to @juanbug’s point, where he states that there’s a realistic concern that large holders would simply delegate their tokens to a burner wallet, or to themselves, without engaging in governance. Why would this pattern play out? Regulatory unclarity. The majority of the stake pool will be composed of $UNI from large token holders, likely VCs, with strict legal mandates. In effect, this does nothing except earn the staker yield and potentially shields them from delegate-delegator liability.

If larger $UNI stakers do opt into delegating to a burn address to avoid the potential liability concerns, then the Foundation’s goal of increasing governance participation could see the opposite effect–holders would still collect staking fees without contributing anything to governance. With the proposed amendment, the protocol could introduce a revised system to push delegation to active delegates or encourage new delegates to appear.

Since the topic was introduced on the forum, multiple ideas for improving the system or addressing its shortcomings have been mentioned.

  • @Banteg’s suggestion is to implement a protocol-wide fee to combat the issue of setting per-pool fees, which may be unsustainable due to the large number of pools and the burden to protocol governance it would present. Gauntlet is currently working through a process to ensure a smooth and gradual procedure for turning on fees on particular pools. The data-driven approach will take time and require delegates to be alert.
  • @Juanbug’s point that the system proposed doesn’t necessarily encourage delegation to active delegates and may lead to the continued limited participation of $UNI token holders in the protocol’s governance.
  • Multiple posts asked about the decision to choose wETH as the payout token rather than other ERC20s. Under the existing system, changing to another token would be impossible. This amendment would allow future delegates that option.

Overall, as experimentation within DeFi continues to expand, we can anticipate that more effective mechanisms and designs will be devised to enhance governance. Given the significant concerns regarding this proposal’s effectiveness in improving governance, restricting experimentation and confining V3 to a potentially ineffective design does not appear to align with the DAO’s best interests. We believe that V3 may better serve as the experimentation ground for governance incentivization, which could prevent issues with future Uniswap versions. If V4 will potentially cannibalize V3’s market share, then experimenting with V3 prior to introducing protocol fees to V4 is a sound approach.

Technical Implementation

Implementation of the setOwner() function is incredibly lightweight from a technical perspective and can be done in less than five lines of code in the v3factoryowner.sol.

function setUniswapV3FactoryOwner(address _owner) external {
    _revertIfNotAdmin();
    FACTORY.setOwner(_owner);
}

The effect of this change would allow the DAO to implement a new v3factoryowner.sol.

Risks

We appreciate that a fully immutable system would reduce the technical risks to the protocol because it would prevent a potential future bug from being introduced or causing operational harm to infrastructure that may someday be built on the Uniswap Staker.

The authors here believe the risk of locking ourselves into a totally new and operationally untested system represents a greater risk to the organization than the proposed technical change and potential future risk considerations.

Next Steps

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.

6 Likes
2

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.

1 Like
3

The poll is live: link

4

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!

2 Likes
5

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?

6

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.

7

I don’t think the cost are worth the meaningful benefits here. My logic is as follows:

  1. 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.

  2. 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.

  3. 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.

8

Thank you for the post. We appreciate the perspective.

  1. 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.

  2. 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.

  3. 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.

9

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.

1 Like
10

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.

3 Likes
11

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

12

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–

But it could also be a hassle to use treasury funds for steering votes as opposed to embedding a steering method where, for instance, delegators who select wallets that vote more receive higher compensation.

^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.

2 Likes
13

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.

2 Likes
14

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.

2 Likes
15

any update ? fee switch activation topics seem stuck

1 Like