Making Protocol Fees Operational
Summary
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: https://info.uniswap.org/ https://defillama.com/protocol/uniswap
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:
- Setting the pool’s fee
- Collecting the pool’s protocol-earned fees
- 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
- Do you agree Uniswap does not need to offer substantial fee rebates to liquidity providers?
- Do you agree a one-fifth fee tier is the appropriate starting point for a protocol fee?
- Do you agree a new system for fee management is a good approach to carrying out the necessary maintenance surrounding the fee switch?
- Do you agree implementing the system on Polygon is a good first step?
- 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.
