Making Protocol Fees Operational

Making Protocol Fees Operational


We propose implementing a protocol fee equal to ⅕ of the pool fee across all* Uniswap v3 pools and turning on the fee switch for Uniswap v2. The scope of this proposal is to implement a fee for Uniswap pools, implement a system to claim earned fees, and trustlessly sell the fees earned for an asset designated by the UNI community. In a subsequent proposal, the UNI community can decide how to manage, allocate, distribute, or otherwise utilize the assets accrued to the treasury.

With the community’s support, the Uniswap v3 Polygon deployment will be the initial deployment to implement the system. After a successful implementation, a subsequent proposal will be made for the Ethereum deployment, and others as deemed necessary by governance.

*All pools with regular volumes that would generate an annualized income over $10,000 for the protocol.

Current Deployments Overview

Uniswap v2 and v3 are Uniswap’s primary protocols. Uniswap v3 Ethereum has about $2.4b in total value locked (TVL) and has daily volumes between $11b-$400m. Uniswap v2 has about $1.1b in TVL and averages approximately $75m in daily volume.

Other Uniswap v3 Deployments*:

  • Polygon: $128m TVL – $45m 24hr Volume
  • Optimism: $80m TVL – $21m 24hr Volume
  • Arbitrum: $1.7b TVL – $244m 24hr Volume
  • Celo: $9m TVL – $0.2m Volume
  • BSC Chain: $10m TVL – $10m 24hr Volume

*May 9th, 2023 - Calculating TVL and volume on a DEX is particularly difficult due to the number of tokens. These statistics may need to be more accurate but should paint a sufficient picture. Resources:

Why Turn On Fees?

Uniswap is in a strong position to turn on protocol fees and prove that the protocol can generate significant revenues. Uniswap is a decentralized exchange, and market participants are used to paying fees to utilize exchanges. We need to reaffirm that liquidity providers are protocol users and do not need full rebates. The LPs making the most money off Uniswap are not retail traders. They are professional market makers, just like the ones seen on traditional exchanges. Trading on Uniswap is similar to trading on a traditional exchange except for the speed at which things occur.

Below is a comparison of what Uniswap charges users and what popular exchanges charge their users.

Binance Fees Maker Taker
< 1,000,000 0.10% 0.10%
> 1,000,000 0.09% 0.10%
> 5,000,000 0.08% 0.10%
> 20,000,000 0.07% 0.10%
> 100,000,000 0.07% 0.09%
> 150,000,000 0.06% 0.08%
> 400,000,000 0.05% 0.07%
> 800,000,000 0.04% 0.06%
> 2,000,000,000 0.03% 0.05%
> 4,000,000,000 0.02% 0.04%
Coinbase Advanced Fees Maker Taker
< 10,000 0.60% 0.40%
< 50,000 0.40% 0.25%
< 100,000 0.25% 0.15%
< 1,000,000 0.20% 0.10%
< 15,000,000 0.18% 0.08%
< 75,000,000 0.16% 0.06%
< 250,000,000 0.12% 0.03%
> 400,000,000 0.08% 0.00%
Uniswap v3 Maker Taker
> 0 - 0.01% Pool -0.01% 0.01%
> 0 - 0.05% Pool -0.05% 0.05%
> 0 - 0.30% Pool -0.30% 0.30%
> 0 - 1.00% Pool -1.00% 1.00%
Uniswap v3 with 1/5 fee Maker Taker
> 0 - 0.01% Pool -0.008% 0.01%
> 0 - 0.05% Pool -0.040% 0.05%
> 0 - 0.30% Pool -0.240% 0.30%
> 0 - 1.00% Pool -0.800% 1.00%


Uniswap is the only major exchange that pays Makers (in DeFi lingo - Liquidity Providers).

Fee Switch Protocol Income

Protocol Fee 6-month Protocol Fee Revenue
1/4 $65,183,978
1/5 $52,147,182
1/6 $43,455,985
1/7 $37,247,987
1/8 $32,591,989
1/9 $28,970,657
1/10 $26,073,591

We gathered protocol volume data for each pool and deployment since their inception. The table above is the hypothetical fee revenue the protocol would have generated over the last 6 months (taken from May 7th) if Uniswap had the protocol fee in the left column across all Uniswap v3 deployments. Of course, this snapshot is not entirely accurate because it doesn’t account for the effect of the fee tier enabled and various other factors. That said, our industry is volatile; protocol volumes can boom and bust regardless of the protocol fee.

All Deployments Lifetime Protocol Fees (⅕) 6-month Protocol Fees (⅕)
Ethereum $281,655,289 $39,612,161
Polygon $6,522,706 $2,446,838
Arbitrum $13,720,260 $8,279,880
Optimism $3,983,873 $1,697,055
BSC $102,061 $102,061
Celo $14,715 $9,188
Total $305,998,902 $52,147,182

Uniswap v2

The term “fee switch” was popularized because Uniswap v2 has a single variable that dictates whether the protocol takes a fee. The Uniswap v2 factory contract has a variable feeTo, currently assigned to the 0x0000… address. Each Uniswap pool checks to see if this address is set to something, and if so, then fees will accrue to the address.

All Uniswap v2 pools have a 30 bps swap/taker fee. Presently, the 30 bps is fully paid to the liquidity providers (LP) in the pool. Once the fee switch is enabled, 5 bps will be saved as an LP share in the pool, and the remaining 25 bps will go to the LPs.

The Uniswap v2 factory contract has a function setFeeTo(address) which the FeeToSetter can call. The FeeToSetter is another smart contract owned by the Uniswap Timelock contract. Governance can turn on fees by calling the toggleFees(bool) function. As currently configured, fees will accrue to the FeeTo contract.

The FeeTo contract is owned by governance, but its ownership can be transferred to another destination. It is this contract that can claim fees from the Uniswap v2 pools.

v2 fees accrue when a mint/burn function occurs. The mint/burn function checks to see if the pool’s K (product) has improved since the last liquidity event. A trade must have occurred if the K has increased, and the pool will mint a UNI-LP token to the FeeTo address. The FeeTo address can redeem the LP token for the underlying components.

Uniswap v3

Now that the process for collecting fees on Uniswap v2 is understood, let’s turn to v3.

v3 sets fees on a pool-by-pool basis, with a fee of 0 as the default. This default value cannot be changed. This means each new pool would need to have fees introduced individually. Note that v3 limits one pool per pair and fee tier so that no one can make additional pools for a pair and fee tier. Each pool has a setFeeProtocol function that the factory owner controls. The fee may be set to 0, 4, 5, 6, 7, 8, 9, or 10. This is interpreted as one over the set number. For example, a 30bps fee tier pool with a parameter of 10 would be a 10% protocol fee and thus would be 3bps to the protocol and 27bps to LPs.

Because v3 pools require individual fee activation, only activating fees on pools with sufficient volume will help governance avoid constantly voting to turn on fees every time a new pool is deployed. We recommend activating fees only on pools expected to generate at least $10,000 in annualized income for the protocol.

Fee Claiming

Once the fee is set, the protocol fees will begin to accrue. To claim fees, the factory owner can call the collectProtocol function(address, amount, amount).

Due to the factory owner being the timelock contract, the protocol must initiate a governance proposal to adjust fee parameters and claim the protocol’s accrued fees. Not only would this be an inefficient process for the protocol to upkeep, but it would also likely run into the block’s gas limit if it were to try to claim for all pools. However, the owner of the factory contract could be changed to a new contract that can sit between the timelock and the factory. This new contract could have a separate, more appropriately equipped system for managing the claiming of fees.

Fee Management

As fees accrue, the protocol should claim and sell the tokens to minimize the protocol’s long exposure to the assets it is earning. The system must sell the protocol assets without relying on any person or entity. Assets must be sold through a transparent, trustless, and open system while functioning objectively.

We propose a solution that allows anyone to pay the gas to collect the fees, sell the fee tokens automatically via the Uniswap auto-router, and then send the proceeds to the protocol treasury. This effectively means the protocol has a resting offer to sell its accrued fees. MEV bots and other parties can wait until the resting order opens an arbitrage opportunity; once profitable to execute, anyone can execute the order.

Development Process

While the Uniswap v3 protocol is non-upgradable, the community should view these proposed changes as requiring a new module to be added to the core protocol. Since the protocol is non-upgradable, the protocol needs to implement new contracts to manage the additional actions. First, a new ownership setup of the Uniswap v3 factory contract to empower the DAO to manage protocol fee-related actions effectively. Second, a contract that handles the claiming of protocol earned fees, selling them for the protocol’s designated treasury asset, and transferring the assets to the protocol’s treasury.

The protocol needs to be able to effectively carry out the following actions for a large number of pools:

  1. Setting the pool’s fee
  2. Collecting the pool’s protocol-earned fees
  3. Selling the pool’s protocol-earned fees

As it currently stands, the DAO would need to make a new governance proposal each time any one of these actions would need to be taken. Due to onchain votes taking 10 days and having a maximum number of 10 actions per proposal means, the DAO has to pursue an alternative solution – a separate system/governance for protocol fee-related operations.

The first option is to change the existing governance contract to allow more than 10 actions; however, this solution would mean regular governance proposals to claim fees, likely leading to poor management of the fees accrued in pools.

The second option is to change the governance structure to make proposals easier to pass; however, the governance system controls the $2b Uniswap treasury, so we shouldn’t do anything to jeopardize the treasury’s security.

The third option, our preferred route, separates the actions related to protocol fee management from the rest of the system. By implementing a new owner on the Uniswap v3 factory contract, we can better define access to the key functions required for protocol fee management. For example, the setFeeProtocol function could require the same quorum that the current governance system has but can be called well over 10 times in a proposal. In addition, we could allow anyone to call the function collectProtocol function but predefine the function’s allowed parameters, like the recipient parameter being the fee-selling contract.

Tax & Legal Concerns

For as long as the fee switch has been debated, people have been concerned with the legal and tax ramifications of activating it. We’ve had numerous conversations with Uniswap delegates, key stakeholders, and DeFi participants at large to understand the scope and depth of the concerns. Through our conversations, we’ve found that the primary concern is around the distribution/use of the earned fees and the possible tax implications of collecting fees. GFX Labs is not equipped to provide, and is not giving the protocol or those reading this post, advice on the best course of action concerning this proposal’s legal and tax concerns. We have separated the protocol fee discussion into two distinct conversations. One is the technical implementation of accruing fees in pools, collecting the accrued fees, and selling the accrued assets to a protocol-designated asset to be held in the treasury, and a separate conversation of how the assets in the treasury could be distributed, spent, or otherwise utilized.

For voters concerned about the possible tax consequences of collecting a protocol fee, note that the protocol has the treasury to answer any necessary call for paying taxes until the protocol utilizes the treasury. At which point, the protocol will decide on how the treasury should be managed. For the purposes of this proposal, treasury management is out of scope.

Next Steps

This proposal introduces a possible structure for implementing protocol fees. Before we get into the smart contract development and implementation details, we would like to solicit UNI voters’ feedback on the proposal.

Key Questions For Voters

  1. Do you agree Uniswap does not need to offer substantial fee rebates to liquidity providers?
  2. Do you agree a one-fifth fee tier is the appropriate starting point for a protocol fee?
  3. Do you agree a new system for fee management is a good approach to carrying out the necessary maintenance surrounding the fee switch?
  4. Do you agree implementing the system on Polygon is a good first step?
  5. What token do you think the DAO should trade fee income for to be held in the protocol treasury?

We’ll let everyone process the above post for at least two weeks before putting up a temperature check. If the temperature check is successful, we’ll update this thread with more information regarding a proposed development process and schedule.


I honestly don’t see a reason for the fee switch to be turned on. Yeah, it’s clearly technically feasible, and your implementation makes sense - but that doesn’t mean we should go forward with development just because we can.

Here’s a quick overview of the benefits of turning on the fee switch:

  1. Uniswap DAO accumulates a larger treasury (they already have the second largest one, I suppose we could go for gold)
  2. I suppose the token price probably goes up a bit

Here’s my take on the downsides:

  1. The DAO has shown it’s quite bad at allocating funds efficiently - not that it’s the DAO’s fault. DAOs are just really difficult to operate as businesses (look at how complicated Maker has become to attempt to do so). So I’m not even sure we could use the money effectively, even if we wanted to.
  2. We’d be wasting a massive token price catalyst in the middle of a bear market.
  3. V3’s business license just expired. Turning on a fee switch and making it easier for forks to compete seems like a very bad idea. If the fee switch was turned on I’d bet the number of serious V3 forks doubles in a month. Why invite more competition without a very good reason?
  4. The legal and tax risks of turning on the fee switch are massive - and I don’t think it’s fair to skate over them in this proposal. The current administration is extremely crypto-hostile, Uniswap Labs is US-based, and rumor has it that Labs is/was being investigated by the SEC already. Why would we give the feds even more reason to come after Uniswap by making the token look more like a security?

If we want to move towards turning on the fee switch, I think a much better idea would be selling a portion of the UNI in the treasury. If it turns out the DAO can effectively allocate those funds and handle the legal and tax ramifications of the sale - then let’s start thinking about turning on the switch.


Totally agree, especially on the SEC and tax concerns. These points have to be solved first, and only after that we shall discuss how the fee switch should be set (personally I would start with 1/10 instead of 1/5). And also we should simultaneously develop an idea how to use these funds (imo buyback and burn of UNI seems the easiest way) cause just accumulating don’t seem a good use-case to me.


Buy-back of UNI should be the default case for the treasury. I see no value in turning on the fee-switch to grow the treasury pot without using incoming funds for anything other than strengthening the treasury and extending the operational runway for the DAO. Maybe an additional % is burned to provide some positive price pressure on the UNI token itself.
Actual implementation of doing that is another thing entirely however.

As for the fears about SEC and hostile crypto regulation: quite frankly, not my problem. Im not a US resident, and I dont care what the SEC thinks of UNI. If crypto and DAO structures are supposed to be as decentralized and resilient against state intervention as we all keep saying it is, then we meet regulation head on.

As for UniLabs, an SEC investigation if the community turns on the fee-switch is a UniLabs problem. Not the DAOs. We can of course (and should) vote to use treasury funds to support Unilabs in the event of such litigation.


Uniswap Fee Switch Q/A - part: 1

  1. The protocol already has a large treasury; what is the point of generating income?

It’s a misconception that the protocol has a large treasury when ~100% of the treasury is UNI tokens. Each additional UNI spent from the treasury diminishes the value of the existing UNI due to increasing the circulating supply. Uncirculated UNI may as well not exist, and its use is akin to minting more UNI tokens; they are equivalent.

Rather than fund initiatives such as the Defi Education Fund, the Uniswap Foundation, the Protocol Guild, and others by increasing the circulating supply of UNI, the protocol could use the fee income to support these initiatives and new ones. Ultimately, it is entirely up to the DAO to allocate these resources. However, we can’t debate treasury allocation when the protocol doesn’t have income to allocate.

Relevant to this discussion, the DAO will likely see a request from the Uniswap Foundation for ~$40m in the not-distant future. While the Uniswap Foundation was initially funded with $20m, their full request was closer to $60m.

  1. Why won’t LPs leave?

LPs have free will. They can choose which protocol to deploy capital to, and at Uniswap, they can choose between 4 different fee tiers to participate in. If they think they can make more money elsewhere, they can go elsewhere. However, they must remember who is paying them. It isn’t the protocol paying them; it is the folks swapping through the protocol. More specifically, people on the Uniswap frontend swapping, which only drives volume to the underlying protocol. As of May 1st, 80% of the volume on Uniswap Ethereum was done directly with the protocol rather than using an aggregator.

LPs can leave, but the users will stick with Uniswap, and the remaining LPs will continue to earn significant fees. The below table shows the number of dollars earned by LPs over the last six months. Despite popular sentiment, LPs are making great money.

  1. What about the regulatory implications of this proposal?

GFX Labs is not equipped to address the regulatory implications of this proposal. While GFX Labs is based in the USA, the protocol is not based in any one country and has token holders and users globally. We encourage token holders with concerns to voice them and vote with their tokens for their desired outcome.


We (Michigan Blockchain) believe that there certainly needs to be progress made on the fee-switch front, as operationally, this process will take some time to fully complete, from proposal discussions & voting to actual technical implementation–and we believe that GFX is a highly qualified team to spearhead this initiative due to their track record in Uniswap governance.

Summary of our decision:

  • Fee switch should be activated, and collected fees should be directed to the treasury
  • Fees should be converted to USDC for hedging treasury’s downside risk due to $UNI overexposure (an understatement)
  • More conversations should be had regarding long-term treasury management (separate proposal for this)
  • Polygon or Arbitrum seem like fitting ecosystems to start fee switch implementation
  • All pools with sufficient volume may be activated, but the ⅕ fee tier is aggressive and should be lowered
  • Most of the operations here are sound, but the biggest bottleneck is the legal clarity, which, in our eyes, cannot be a separate discussion as the implementation of the fee switch hinges on the legal/tax. Since GFX provides technical expertise, we believe a simultaneous legal discussion needs to be fleshed out in parallel with this proposal. The main consideration here will be regarding income tax and not securities law since, according to this proposal, the DAO alone will have income, but other stakeholders like $UNI holders won’t (yet) receive dividends. A justifiable compromise, however, may be paying any income tax from the USDC that the treasury holds upon the DAO’s approval.

Treating Uniswap as a Business

An important consideration we need to think on is the mismatch between protocol value creation vs protocol value accrual. Uniswap has been an extremely valuable asset to the industry, available on multiple chains, driving billions of dollars of volume daily. As far as PMF goes, Uniswap has it–and in compensation, the protocol should earn a due portion of the fees. No revenue for the protocol effectively makes Uniswap an unprofitable business, and as delegates, we ideally like to view the protocol as a self-sustaining business. This is one of the reasons why we’ve been such large proponents of multi-chain expansion, which is akin to evolving a domestic corporation into a multinational enterprise.

Of course, the current treasury has an AUM of ~$2B–which can be heavily discounted since 99.9% of it is in $UNI tokens–so the protocol is overall financially sound. But a strong balance sheet does not warrant an absent cash flow stream. Therefore, we are in favor of generally implementing the fee switch. The caveat is that treasury management should become a more important focus for the DAO (the specificities are out of this proposal’s scope). So what should we do with the fees earned from the fee switch? We should begin diversifying the treasury by converting the earned yield into a mixed pool of stablecoins to hedge the treasury’s downside. For simplicity, we can just start by selling the collected fees for USDC. Evidently, the treasury has lost 87% of its value over the past 2 years, so this seems like a logical step forward while a more robust treasury management plan is fleshed out.

Ecosystem Selection

As for which ecosystem’s fees should be turned on, Polygon seems like a good choice. A primary concern about the fee switch is that Uniswap will lose market share in the ecosystems that enact the fee switch as it becomes less favorable for LPs (makers). But YTD, v3’s volume-based market share on Polygon has straddled between 70% - 85%, generally increasing over time (this data is a month behind). Although Quickswap on Polygon still drives large volume, like today, it had $225M of volume vs Uniswap at $370M. Arbitrum is another good contender. Optimism is less favorable than Polygon and Arb since Velodrome still has sizable market share in the OP market. Overall, we’re good to start with either Polygon or Arbitrum, with a bias towards Polygon.


Legal Clarity is the Bottleneck

That being said, our main concern remains the legal side. How will the protocol go about paying income tax? We realize that this question is outside the scope of the proposal–but doesn’t seem like a viable direction to adopt since the rest of the proposal seems to hinge on the regulatory clarity behind enacting the fee switch. And since that is one of the most prominent bottlenecks, we believe that legal considerations must be taken into account in parallel with a technical/operational proposal like this one.


Awesome to see a detailed proposal on this topic from highly competent delegates that can see it through to deployment!

I think many community members and delegates would vote in favor of this proposal as is, with the default token that’s swapped for and held in treasury to be ETH.

On the topic of tax implications, I can’t seem to follow the logic or concerns raised in this thread. The primary concern seems to be that the protocol has tax liabilities once a fee switch is activated. By that logic, every ETH holder (or validator) would have tax obligations for pending transaction fees in the mempool even if they don’t receive them directly.

The above logic could also be applied to BTC holders (or at home miners). They too would have tax obligations for the transaction fees pending in the mempool even if they don’t receive them.

A more direct example would be the Compound DAO which has control over the protocol reserve which accrues cTokens paid by borrowers. Every Compound market has a Reserve Factor which represents a portion of borrower’s interest that is converted to protocol reserves.
I should note that Aave protocol functions similarly to Compound in regards to the above example.

Surely we’re not suggesting that Compound or Aave DAOs owe years worth of taxes for simply having control over the protocol reserves :sweat_smile:

If the concerns around tax implications were legitimate, wouldn’t we have to assume that every single vested UNI that has accrued to the DAO controlled treasury caused a taxable event? UNI token holders do control that treasury the same way they would with a fee switch pool after all.

I feel like its a bit of a reach, to be quite honest, and I don’t think there is sufficient precedent to impede a proposal such as this one for the cited tax reasons unless there is a legal professional that can provide case law to the contrary.


Greetings! Can someone explain me how regular liquidity providers would benefit from turning fees on? And can you specify a simple example of a fee which a regular liquidity provider should be paying?
Also, have you calculated the potential impact of this proposal on earnings and on customer churn/influx?

1 Like

I would say buy back UNI and burn 100% of it. Managing treasury funds have proved erratic at best. Burning ‘should’ drive UNI’s utility and - one would think - price. The Treasury can sell UNI then and deal with diversification and other strategies.


Interesting post @GFXlabs! I think you raise great points about collecting fees. Capturing fees from thousands of token pairs would be a logistical nightmare.

We had a similar problem to solve for PoolTogether V5, so I want to share our solution with you!

Our Requirements:

  • Needed a mechanism to sell token A for token B
  • Token A accrues slowly, and Token A liquidity is held in an external contract
  • Cannot use an oracle, because there will be obscure tokens
  • Must be fully automated, because there will be many tokens
  • Is not prescriptive on where liquidity comes from; it should be open and allow token B to come from anywhere.

Our Solution:

The Liquidation Pair: a single-sided virtual AMM based on the CPMM x*y=k. You can find the full explanation here.

Here is the Liquidation Pair on Github

The Liquidation Pair has Token A and wants Token B, so it only supports B → A swaps.

How it works:

  • The Liquidation Pair stores a virtual reserve A and reserve B amounts. These are configured at creation time. Generally we just make sure it’s a small amount.
  • The “total” reserve A is actually virtual reserve A + available A liquidity, so as liquidity accrues the liquidity balance shifts and it becomes an arbitrage opportunity
  • Arbers swap Token B for Token A when the shift becomes profitable
  • The tokens from the arb can be sent anywhere and trigger a callback; that is configured when the liquidation pair is created.

The algorithm also includes an additional mechanism to ensure the liquidation price tracks the market price accurately and adjusts K automatically so that the virtual reserve amounts are proportional to the rate of accrual. See the link to the full explanation above!

If you move forward with the proposal, then I hope you find the code useful! The PoolTogether team is happy to answer any questions you have. Feel free to join our #developer channel.


Thanks for the proposal @GFXlabs!

The discussion around Uniswap’s fee switch has been ongoing for a while now with various alternatives proposed, introducing different trade-offs at various levels of the protocol. Tax implications aside, the idea of a fee switch seems counterintuitive at the protocol level as it directly levies a tax on LPs, and indirectly on users (traders) assuming liquidity diminishes. It’s also probably hard to find a mechanism that uses the revenue from the fee switch to generate a surplus for the protocol (i.e., post-fee switch revenue > pre-fee switch revenue).

However, if we think about revenue benefits at the DAO level it can begin to make sense for the protocol to start accruing fees to the DAO’s treasury to ensure Uniswap’s longevity. Largely, reducing the need to sell large amounts of UNI to fund development and operational costs, which come at the cost of UNI holders. But more importantly, becoming a self-sustaining DAO through revenue earned by the protocol.

So we encourage the experimentation of the fee-switch and think that Uniswap is in a good position to do so. We also believe that once live, having an active treasury opens up the next chapter of decentralization for the protocol as it begins to attract service providers from the treasury management realm and ‘risk’ teams to assess which pools should have an active fee switch.

Some thoughts on your questions:

  1. Do you agree Uniswap does not need to offer substantial fee rebates to liquidity providers?

This is slightly misguided as there are major exchanges that offer maker rebates (e.g. Bybit). However, most of these fee structures are only available to high-volume liquidity providers. Nonetheless, we believe the current rebates are sufficient even with a 1/5 protocol fee; catering to Uniswap’s supply side is important for the protocol to remain competitive.

  1. Do you agree a one-fifth fee tier is the appropriate starting point for a protocol fee?

Yes, it’s likely sufficient enough to understand the implications of the fee switch and somewhat in line with what order book exchanges capture at the higher end of their discount tiers.

  1. Do you agree a new system for fee management is a good approach to carrying out the necessary maintenance surrounding the fee switch?

The proposed solution is great and allowing anyone to call the fee collector contract is a nice addition. Having the ability to call setFeeProtocol over 10 times is important for reducing governance fatigue.

One question we had and is related to Q5, will there be a token whitelist function that blocks certain tokens from being sold when the fee collection contract is called? e.g. If the DAO decides ETH, USDC, and USDT are assets that want to be held, it doesn’t make sense to sell these assets only to rebuy them in the token consolidation phase.

  1. What token do you think the DAO should trade fee income for to be held in the protocol treasury?

We don’t have a strong opinion on this but an obvious starting point would be a set of stablecoins to begin building a safe and strong financial foundation.


Thanks for writing this up! It’s an exciting proposal.

I think this proposal is a nice iteration in several ways over the one that @guil-lambert and I wrote up. However, I am going to focus on where I’d like to see continued work before I would support it.

I believe this proposal shares the same weakness that the proposal Guillaume and I had… it does not address what to do with any fees collected.

I’ve come to the strong belief that any fees collected by the protocol should be autonomously distributed in a programmatic way. There is a big design space in what that could look like but the main point is that they should not simply collect to a treasury where they are then arbitrarily distributed based on later token votes. My reasons for this belief are the following:

  1. Token holders have a very poor track record in managing protocol treasuries via discrete voting. It has not proven to be efficient or effective.

  2. Ideologically, this is much more aligned with traditional crypto ethos of immutable, forever software. Contra some other commenters, I strongly disagree with the view that the Uniswap protocol is a business… it absolutely is not a business. It is an autonomous piece of software, it doesn’t have employees, it can’t go bankrupt, it doesn’t have revenue and expenses. Protocols are a revolutionary new entity type and we need to think of them as such.

  3. Although we would still need to be thoughtful about regulatory and tax considerations, the autonomous redistribution should be a much more vanilla tax / regulatory position (i.e. this is the same as how ETH staking works).

I think this proposal is a step in the right direction but the crucial piece I outlined above needs to be addressed before I can support it.


Relaying Leighton’s post:

A trustless system designed to collect fees in the pool, and swapping the protocol fees to be claimable for a designated token should add no more additional taxation responsbility to what LPs are currently responsible for. Unless there is a legal & taxation professional to contest, it appears straightforward that eliminating the requirement for a common enterprise to manage fees also eliminates the debate of legal & taxation concerns. Anecdotally, I’ve never seen any hard evidence on cited laws within these forums proving any impact to the intersection of Uniswap Protocol, Uniswap Labs, and its users regarding the legality of the protocol fees. Unless the cited laws carry merit to being catastrophic towards furthering the protocol fee, the community should just cope with the idea that you can sue anyone for anything.

I believe activating the protocol fee is fairly zero-sum. Here are some reponses to the fantastic proposal:

  1. Do you agree Uniswap does not need to offer substantial fee rebates to liquidity providers?

In a different lens, turning on the protocol fee could provide a like-for-like rebate via a hedge for LPs. In light of the fact that Liquidity Providing in volatile Uniswap pairs without considering a larger strategy - absent of protocol revenue mechanisms to hedge - is simply a bad idea.

  1. Do you agree a one-fifth fee tier is the appropriate starting point for a protocol fee?

Yes, a one-fifth fee tier represents a negligble impact to Liquidity Providers. It’s reasonable to assume that the overwhelming amount of users will always trade on Uniswap regardless of price impact - mostly because they don’t bother to check agregators or other DEXs for fractional savings in slippage. There has been some great research done by @rfritsch on this:

  1. Do you agree a new system for fee management is a good approach to carrying out the necessary maintenance surrounding the fee switch?

Yes, and I believe that funding the design of a PoC system, writing the smart contract(s), and a third-party audit of a deployment strategy is well-suited use of treasury funds.

  1. Do you agree implementing the system on Polygon is a good first step?

Testing on Polygon and Arbitrum seems fitting before deploying on mainnet.

  1. What token do you think the DAO should trade fee income for to be held in the protocol treasury?

Protocol fees should be converted to the native protocol token: UNI. Trading fee income to stablecoins or alternative tokens should be decided upon by the claimant.


It is great to make our first post about the Fee Switch. Some background about Native, we are a boutique advisory firm founded by @Kydo

We are thankful to @GFXlabs for producing an informative post on the Fee Switch. It effectively outlines the mechanism of the Fee Switch and provides data on its implications. We also recommend delegates to revisit @Stastny’s post here regarding their Fee Switch report.

Close to 300 forum messages have been exchanged in the Fee Switch discussion, and, as @Leighton has mentioned, we have not made much progress. We believe there are two primary reasons for this.

The minor factor is the lack of on-chain votes tracking our progress in the conversation. We should be continuously making progress on the previous discussion instead of having one vote to sort everything out.

The principal cause is the regulatory ambiguity surrounding the Fee Switch. The tax and security-like implications have significant consequences for those currently working at the lab and the foundation.

Nevertheless, we cannot wait for regulation forever.

This is Native’s proposal to move past this stalemate. The idea is to slowly build towards a comprehensive fee switch design (legal, smart contract, future fee usage, etc)

We should break down this decision into smaller parts and set a deadline for the Fee Switch to be activated. If the Fee Switch is not turned on by the deadline, a simple backup strategy will be executed (eg. all main v3 pools on Polygon will be turned on).

Here is our proposed plan:

  1. DAO votes on whether the Fee Switch should be activated in the future (time and mechanism indifferent).
  2. DAO decides on a backup Fee Switch plan and deadline for a Fee Switch decision (time and mechanism sensitive).
  3. DAO establishes a committee to propose a plan on the legal and mechanism design for the Fee Switch.
  4. If the DAO approves the committee proposal, the backup Fee Switch plan is forfeited.
  5. If the DAO does not approve the committee proposal before the deadline, the backup plan is implemented.

We do not consider this to be the definitive plan to bring about meaningful change for the protocol; however, we are confident that making gradual progress is essential to the conversation about the fee switch.

Answering @GFXlabs originally proposed questions to keep the conversation moving forward:

  1. Do you agree Uniswap does not need to offer substantial fee rebates to liquidity providers? Unlike traditional markets, the Uni LP’s strategy space is much more limited, therefore the high rebate is not as unjustified. However, we do believe exploring with the exact rebate amount is meaningful.
  2. Do you agree a one-fifth fee tier is the appropriate starting point for a protocol fee? Yes.
  3. Do you agree a new system for fee management is a good approach to carrying out the necessary maintenance surrounding the fee switch? Yes given the rigid collectProtocol() function.
  4. Do you agree implementing the system on Polygon is a good first step? Yes. We are indifferent among the L2s.
  5. What token do you think the DAO should trade fee income for to be held in the protocol treasury? USD-stablecoins and ETH are both acceptable.

Based on my understanding, previous fee switch proposals did not originate from highly active delegates, such as GFX Labs, who possess substantial UNI delegations and have already presented multiple Uniswap proposals from Forum Discussion to on-chain voting and execution. This lack of active follow-up by previous proposers, possibly due to other commitments or limited resources, could be a contributing factor in their proposals not gaining much traction.

Regarding the mentioned concerns about taxes, I would like to inquire about your thoughts on the fact that the treasury has been accumulating value in the form of vested UNI tokens since September 2020. How do you perceive the distinction here? If you consider the control of a value-accumulating treasury as equivalent to running an enterprise, what about the billions of dollars that have gradually vested to the DAO-controlled treasury over nearly three years? Drawing a parallel between a fee switch pool controlled by the treasury and a UNI pool controlled by the treasury, which vests UNI tokens created by Uniswap Labs, doesn’t require legal expertise. This is particularly evident when considering that the UNI tokens from the treasury have been utilized to pay for services and grants.

Furthermore, I have mentioned other examples in this thread, such as the Compound and Aave protocols, both of which have a concept called a ReserveFactor. This function enables the protocol to accumulate value through debt tokens paid by borrowers and controlled by token holders. Recently, AAVE token holders voted to utilize a portion of their protocol reserves, showcasing complete autonomy over DAO-controlled assets.

The main point I wish to emphasize is that the tax and security concerns raised about the Uniswap DAO and its token do not have basis in precedent, yet they continue to be reiterated on this forum. Another U.S.-based protocol, Compound, has already established a clear precedent on this matter, which Uniswap has structurally mirrored in many ways.

I fail to comprehend how we can expect highly active delegates to disregard community support and token holder approval, especially when previous snapshot polls have shown support for some form of fee switch. It seems inappropriate to impede this proposal due to opinions on the forum that lack factual basis and do not align with the technical functioning of blockchain protocols.

For those expressing “legal concerns” regarding this proposal, it would be more appropriate to reference legal precedents rather than relying on views propagated on Twitter or elsewhere. Many law-abiding protocols, including Uniswap, already possess a value-accumulating treasury.

Adopting the legal stance that some have voiced in this thread would essentially mean that almost every DAO (once again Uniswap included!) are already violating tax laws.

Since this proposal is a technical one that does not aim to distribute the funds accrued by a DAO-controlled pool, I believe it is best to encourage further technical discussions at this stage, allowing us to focus on the remaining technical uncertainties.

If there are genuine legal concerns, the proposers deserve well-founded arguments supported by facts, either from legal professionals or by citing relevant case law, explaining why they should not proceed with the proposal after receiving feedback.

Ultimately, if this proposal indeed carries catastrophic legal implications, those with voting power who hold such concerns should exercise their votes when we proceed to an on-chain vote. This approach would be the fairest way forward, adhering to the protocol’s rules and to token holders’ beliefs.


We agree that this is the best path forward.

Moreover, we agree this thread is best kept around the technical questions. For us to discuss legal matters here are not useful to anyone. To finish this conversation, lawyers most of the time do not and will not post on forums. And these legal questions are real concerns we have heard in private conversations expressed by experienced crypto-native lawyers.

1 Like

Blockworks Research is currently participating in the Uniswap Foundation’s delegate race. While we await delegation, we will continue to be active participants in governance discussions.

We are in favor of GFX Lab’s proposal to move forward with testing the fee switch on Polygon, but require clarity on a few points before voting yes to the proposal.

  1. It should be more clearly stated that this proposal is solely to turn the fee switch on for all Polygon V3 pools, to the tune of 20% of swaps fees, and only applicable to pools with >$10,000 in expected fee revenue. Additionally, we’d like all pools that currently meet this criteria officially listed.

  2. Who will be building the contract that sits between the timelock and the factory? This is a non-trivial task that will require audits as transferring ownership of the factory contract poses extreme risks to the DAO and protocol. We’d like to see a clear and technically specified plan as to this transition.

  3. What token(s) will the proceeds be sold for? “collect the fees, sell the fee tokens automatically via the Uniswap auto-router, and then send the proceeds to the protocol treasury” is not sufficient without a goal of what tokens we’d like the treasury to end up with (EG a mix of 33% USDT, USDC, and ETH). Additionally, we highly recommend the use of an application like Milkman in place of selling via the Uniswap router in order to mitigate MEV and frontrunning. This has been a huge problem for Curve and Sushi who employ similar models.

We agree with Leighton’s sentiment that a discussion around the use of the funds should begin prior to the implementation of this proposal, but disagree that it should pose a roadblock to its passing.

We view this fee switch proposal as an experiment that tests the protocol’s ability to turn on the fee switch without disrupting the DEX. A use for the revenue is far more vital prior to the implementation on mainnet. This should be a barrier to mainnet deployment rather than testing. After all, Polygon V3 pools only make up ~5% of the total V3 volume and ~2.5% of the total V3 TVL.

We have many ideas for using protocol revenue, which we will include in a separate discussion surrounding this topic. Having a diverse and powerful treasury is a huge benefit to the protocol in itself and dependent on total revenue received, the optimal use cases may vary.


TL;DR I strongly disagree with this proposal.

The Uniswap infrastructure is a public good. Turning on the fee switch in this manner would lead to the deterioration of the Uniswap protocol’s public good nature (in a very tragedy of the commons-like manner) and would undoubtedly push the $UNI token closer to being a security.

I’ll try to be concise my response, but for those that want to better understand my competing (?) view, please read this post about how I think the proposal to turn on the fee switch should come from protocols themselves, not UNI token holders.

Why this is bad economics and poor long-term planning

Thinking about the fees switch in terms of revenues misses the point: the Uniswap smart contracts have no expenses, no payroll, and no COE/board/managing entity. The smart contracts will continue to operate long after all of us are dead. To echo what @Leighton has said:

[Uniswap] is an autonomous piece of software, it doesn’t have employees, it can’t go bankrupt, it doesn’t have revenue and expenses. Protocols are a revolutionary new entity type and we need to think of them as such.

The protocol does not exactly “need” revenues to operate. Token holders may want a slice of the pie, but any proposal that enact a return of the collected fees to $UNI token holders would unequivocally make the $UNI token a security – it is easies to make the argument that the $UNI token satisfies the Howey test prongs 3+4: (1) an investment of money, (2) in a common enterprise, (3) with the expectation of profit, or (4) to be derived from the efforts of others.

Espousing a securities role for the $UNI token, the largest DeFi protocol, would certainly create a precedent --and I’m OK if that’s the route the UniswapDAO wants to take-- but it would also create a huge target on the back of the UniswapDAO in the eyes of the sεc and other regulatory agencies.

Answer to Key questions

Thinking in terms of public goods management, the question UniswapDAO voters need to ask themselves is: how is that fee switch proposal contributing to the sustainable growth of the Uniswap protocol (and not of the $UNI token)?

I don’t really grasp how decreasing the revenues for liquidity providers on all* Uniswap v3 pool grows the protocol. LPs can, and definitely will, move to a different fork of Uni v3 if they’re unhappy.

My answers to @GFXlabs’ questions:

  1. Do you agree Uniswap does not need to offer substantial fee rebates to liquidity providers?
  • Not at all. CEXs and DEXs are two completely different economies. Comparing maker-taker fees on CEXs to Uniswap is like comparing the cost of a stamp to the cost of sending an email (ie. look, it costs 0.5$ to send a letter, email should at least cost 0.1$!).
  1. Do you agree a one-fifth fee tier is the appropriate starting point for a protocol fee?
  • I reject the premise that the UniswapDAO should be turning on the fee switch for all* Uniswap v3 pools.
  1. Do you agree a new system for fee management is a good approach to carrying out the necessary maintenance surrounding the fee switch?
  • No. I don’t think we should be compromising on security by implementing a new on-chain system to execute DAO operations. Having to vote every day and potentially spend 30M gas for doing so should not be seen as an “inefficient process for the protocol to upkeep”. It’s a feature not a bug.
  1. Do you agree implementing the system on Polygon is a good first step?
  • No. A good first step would be The Uniswap DAO turning on the fee switch for the ETH-UNI-30bps pool. In fact, all protocols should be requesting to turn on the fee switch on their own token pools. Let protocols XYZ figure out the tax+securities implications for their own token, and let the Uniswap DAO be the credibly neutral overseer of that process.
  1. What token do you think the DAO should trade fee income for to be held in the protocol treasury?
  • I am against the view that the fee switch revenue should touch the treasury in any way. We must first figure out how to handle the tax/securities implications of capture protocol fees, and be ready to jump through Gary’s hoops if the UniswapDAO chooses to make the $UNI token closer to a security.


I firmly believe that the proposal to turn on the fee switch for all* Uniswap v3 pools as described by @GFXlabs should not be enacted.

The Uniswap protocol, as a public good, should prioritize sustainable growth and the overall health of the ecosystem. This involves ensuring liquidity providers are adequately incentivized and maintaining the neutral status of the Uniswap DAO. While revenue generation may seem attractive, it could potentially turn the $UNI token into a security and attract unwanted regulatory attention.

The decisions we make today are shaping the future of Uniswap. It is crucial that we think critically about the long-term implications of any vote, and ensure that they align with the core principles of Uniswap: decentralization, openness, and neutrality.


Love you Guil but your post reminds me of this video:


The protocol does need revenue to have sustainable operations. We like funding ecosystem developments and public goods through the UF. The DAO also needs to continue to pay service providers such as labs to keep iterating and making sure our tech stays competitive.

According to who? I am not a lawyer but a security in the US must have an “expectation of profits from the efforts of a promoter or 3rd party” and I don’t see how UNI unequivocally fulfills that requirement (not a lawyer). Additionally, there is zero indication of that use for revenue in this proposal, making it irrelevant to the discussion around testing the fee switch and seeing if it can be deployed without losing marketshare (what this proposal does cover).

That’s why we are testing it on Polygon which makes up ~5% of total volume. If LPs leave, we will have concluded a successful experiment and head back to the drawing boards with only a slight hiccup to the overall success of Uniswap. Growing Uni as a whole is about bringing more user adoption globally. There are many uses for the revenue that could grow the protocol with this in mind.