I support Uniswap capturing sustainable value from v4, but not without clear protections for the liquidity providers on whom the protocol depends.
Before activating fees broadly, governance should establish transparent measurements of LP profitability, liquidity depth, spreads, volume, and market share, along with predefined review and rollback thresholds. Fees can then be activated selectively where the evidence shows that pools can support them without weakening Uniswap’s competitiveness.
I am voting AGAINST this implementation, not against protocol fees in principle. Build the measurement and rollback mechanism first, then activate fees responsibly.
**Voting For.**
Uniswap is running the experiment the rest of this industry keeps arguing about in theory. Protocol fees have been live across v2 and v3 on eleven chains, Labs has taken its interface, wallet and API fees to zero, and Uniswap is still the largest venue. If volumes hold through this extension, that is an empirical answer to the claim that a protocol must give its service away to defend market share. Extending fees to v4 tests it on the most competitive surface we have. That alone is worth the vote.
Three reasons I support this proposal, and one distinction I want on the record.
**It restores the link between protocol activity and the asset.** This is the property most infrastructure in this space has lost: usage grows and the token does not notice. Uniswap is rebuilding that link rather than deferring it indefinitely.
**It is a credible commitment, not a promise.** Routing revenue to a treasury is a policy any future governance can reverse and any well-organised constituency can capture. Burning is irreversible and admits no discretion. Whatever its drawbacks, it is a commitment device: it signals to holders that this protocol will be operated toward profitability rather than as a permanent subsidy, and it removes the option of quietly abandoning that discipline later.
**It demonstrates profitability without subsidy.** That matters beyond Uniswap. The prevailing argument for keeping fees near zero across this industry is that charging drives activity elsewhere. Uniswap is the only large protocol currently generating evidence either way.
**The distinction: burning is a distribution, not fiscal capacity.** Fees flowing to TokenJar and out to 0xdead do not fund a single line of development. Development is funded by the 20M UNI annual growth budget, which is issuance from a finite, never-replenished stock — economically a capital raise, not revenue. That structure is only non-dilutive when the burn exceeds the issuance.
The threshold is exact: 20,000,000 UNI over 365 days is roughly **54,800 UNI per day**. Below it, Uniswap is funding growth by diluting holders and calling it value accrual. Above it, the growth budget is genuinely self-financing.
This is precisely why the proposal deserves support: extending fees to v4 and to additional chains is the mechanism that pushes the burn above that line. But I would ask the sponsors to publish the trailing 90-day average daily burn alongside the record figure. A record day is not a run rate, and this threshold should be a standing metric rather than something delegates reconstruct by hand.
Strongly against activating fees on v4. See our reasoning here: https://gov.uniswap.org/t/temp-check-activate-v4-protocol-fees/26162/10?u=gammastrategies
Basically we believe it's too early to be activating protocol fees on v4 prior to achieving market dominance.
I support this proposal because it introduces a governance-driven framework for activating protocol fees in Uniswap v4 that is compatible with the protocol's flexible hook architecture. Rather than managing fees on individual pools, the proposed V4 Fee Controller applies transparent, deterministic rules while remaining upgradeable through governance if future adjustments become necessary.
The phased rollout across multiple chains, combined with the use of policy-based fee management and on-chain governance oversight, provides a measured approach to expanding protocol revenue while preserving the ability to refine the system as real-world data becomes available.
I support this proposal because it extends the protocol fee framework to Robinhood Chain using the same governance and infrastructure model already adopted on other supported networks. Reusing the established Arbitrum Orbit implementation minimizes execution risk while expanding protocol fee collection and UNI burn mechanics in a consistent manner. This represents another incremental step toward a standardized multi-chain fee architecture for Uniswap.
# Activate v4 Protocol Fees (Part 1/2)
## Summary
This proposal continues the protocol fee rollout approved in UNIfication, following proposals [#93](https://vote.uniswapfoundation.org/proposals/93), [#94](https://vote.uniswapfoundation.org/proposals/94), [#95](https://vote.uniswapfoundation.org/proposals/95), and [#96](https://vote.uniswapfoundation.org/proposals/96). It uses the expedited governance process where fee parameter update proposals go directly to a five-day Snapshot followed by an onchain vote.
Protocol fees are now live across all v2 and v3 pools on 11 chains - Ethereum, Arbitrum, Base, Celo, OP Mainnet, Soneium, X Layer, Worldchain, Zora, BNB Chain, and Polygon. Last month, the protocol set a record burning [186,000 UNI in one day](https://x.com/UNIBurnBot/status/2063252718043459633).
Below we introduce a system for v4 protocol fees and propose to activate it on a subset of v4 pools on these same chains. This onchain vote will specifically activate v4 fees on Ethereum, Arbitrum, Base, BNB Chain, Polygon, Optimism, and Robinhood Chain. Please note that because of GovernorBravo's limit of 10 actions per proposal, there will be two separate onchain votes to accommodate all chains.
The remaining five chains (Celo, Soneium, Worldchain, X Layer, Zora) will be addressed in a subsequent proposal.
---
## Implementation Details
v4's hook architecture requires a different approach to fee activation than v2 or v3. v2 pools have a single LP fee tier and are charged a static fee. v3 has several LP fee tiers, each charged a static fee. Hooks mean v4 has potentially infinite distinct LP fee tiers, and a pool's fees can change dynamically from one block to the next. To manage this, we propose a V4 Fee Controller system where governance sets rules that let a dedicated contract compute the fee for any pool on demand, rather than setting a fee on each individual pool.
The system splits across two contracts:
* **V4FeePolicy**. Given any pool, it computes the fee from rules defined by governance. This is the contract governance calls to enable and adjust the protocol fee, and it can be swapped out later if the logic for setting fees needs to evolve.
* **V4FeeAdapter**. Enforces governance overrides, so if governance has set a per-pool override, that override wins and the policy is skipped. Otherwise the adapter applies the policy's fee, pushes it to the pool, and collects the proceeds to the TokenJar.
`V4FeePolicy` determines a pool's fee in two steps. First it sorts the pool into a **family**. A pool's family is determined by its characteristics, e.g. whether it has a hook, whether it uses the `PoolManager`'s native swap math, whether it charges dynamic swap fees, et cetera. A pool's family is identified by a flag, which is stored on the hook smart contract. Hook developers can opt their pools into a family via assigning it a specific flag. Governance can also assign a hook to a family directly via a vote.
Once it determines the pool's family, the policy then resolves the fee, applying the rules below, going in order from most specific to least:
1. a per-pair fee, if governance has set one for that token pair in that family
2. otherwise the family's own fee (defined by governance as a default or curve)
3. otherwise a global default for anything still unclassified
With this system, governance manages a handful of rules and overrides instead of an unbounded list of pools, any fee is computed deterministically and can be inspected onchain, and the policy itself is replaceable if governance later wants to change how pools are categorized.
This proposal activates fees on three pool families:
* **Static fee pools:** These are pools without hooks. The protocol fee for these pools is set via a curve targeting a proportion of each pool's LP fee. For a description of this curve, please see the appendix below.
* **CCA Pools**: These are pools launched after a Continuous Clearing Auction. The LBPHook and pools resulting from previous auctions will be opted into the same curve as static pools.
* **Aggregator hook pools:** These are pools whose hooks integrate external liquidity venues into the v4 routing graph. The protocol fee for the aggregator hook family is a flat fee with overrides for specific pair types. To maintain the option of charging more on this external flow than the v4 PoolManager's hard cap of 10bps, aggregator hooks will multiply their assigned fees by 25, allowing for a cap of 250bps. After the multiplier is applied, the resulting fee for aggregator hooks will be:
* For all chains other than Base:
* Family Default: 10bp
* Select Stable Pairs: 3bp
* For Base:
* Family Default: 3bp
* Select Stable Pairs: 1bp
**This proposal does not enable the protocol fee for any pools other than those in the Families mentioned above.**
Fees will flow to TokenJar on each chain. UNI burned on L2s and alt-L1s will be bridged back to Ethereum mainnet and sent to `0xdead`.
---
## Onchain Proposal Spec
**Pre-proposal** (to be completed by Uniswap Labs prior to an onchain vote)
* Deploy V4FeeAdapter and V4FeePolicy contracts on the chains where the v2 and v3 protocol fees are currently enabled (Ethereum, Arbitrum, Base, Celo, OP Mainnet, Soneium, X Layer, Worldchain, Zora, BNB Chain, and Polygon).
* Configure V4FeePolicy contracts with the native math protocol fee curve, CCA Hook and aggregator hook family fee logic described above
These contracts can be found [here](https://github.com/Uniswap/protocol-fees/tree/main/src/feeAdapters), and this post will be updated with addresses and explorer links when they have been deployed.
**In this proposal** (executed if the vote passes):
* Set the `V4FeeAdapter` as the `ProtocolFeeController` on the PoolManager on each chain
---
## Next Steps / Timeline
**Snapshot:** July 11-16, 2026
**Onchain vote:** July 19-26, 2026
---
## Appendix - Static Fee Curve
The V4 Fee Controller allows fee setting using discrete LP fee tier ranges. Each range has a floor, and the next range sets the ceiling. For each range, governance sets two inputs:
* `alpha` which is the constant. This is the starting fee for that range.
* `beta` which is the scaling factor. This is how fast the fee grows within that range. The growth always starts from the floor of the range.
* Inside any range, the fee is: `alpha + beta * (lpFee - floor)`.The output is floored to the nearest 0.01bp increment, consistent with v4's minimum fee resolution.
| *Range (bps)* | *Floor* | *Alpha (bps)* | *Beta (bps)* |
| :---- | :---- | :---- | :---- |
| *0 - 0.03* | *0* | *0.01* | *0* |
| *0.03 - 0.75* | *0.03* | *0.01* | *19/72* |
| *0.75 - 1* | *0.75* | *0.2* | *0.2* |
| *1 - 3.75* | *1* | *0.25* | *3/11* |
| *3.75 - 5* | *3.75* | *1* | *0.2* |
| *5 - 25* | *5* | *1.25* | *11/80* |
| *25 - 55* | *25* | *4* | *0.2* |
| *> 55* | *55* | *10* | *0* |
This results in the following fees at the following points.
| LP Fee (bps) | Protocol Fee (bps) |
| :---- | :---- |
| 0.03 | 0.01 |
| .75 | 0.20 |
| 1 | 0.25 |
| 3.75 | 1 |
| 5 | 1.25 |
| 25 | 4 |
| 30 | 5 |
| 83.34 | 10 |
| 100 | 10 |
# Protocol Fee Expansion: Robinhood Chain
*This proposal is part of the protocol fee rollout, following proposals [#93](https://vote.uniswapfoundation.org/proposals/93), [#94](https://vote.uniswapfoundation.org/proposals/94), [#95](https://vote.uniswapfoundation.org/proposals/95), and [#96](https://vote.uniswapfoundation.org/proposals/96). It uses the expedited governance process [approved](https://gov.uniswap.org/t/unification-proposal/25881#p-57882-protocol-fee-rollout-4) in UNIfication, where fee parameter update proposals can bypass the RFC stage and go directly to a five-day Snapshot followed by an onchain vote.*
Since protocol fees went live on Ethereum mainnet in late December last year, the rollout has extended to ten additional chains: Arbitrum, Base, OP Mainnet, Worldchain, X Layer, Soneium, Zora, Celo, BNB Chain, and Polygon. The burn system is working as designed, with fees accumulating in TokenJars across chains. From there, searchers claim them in exchange for burning UNI by bridging it back to mainnet and sending it to the burn address.
Uniswap [launched on Robinhood Chain](https://blog.uniswap.org/robinhood-chain-is-live) at the chain's July 1, 2026 mainnet debut, with v2, v3, and v4 all live. As of July 10, the deployments have crossed $6b of cumulative swap volume. This proposal:
- Extends the infrastructure for collecting and burning protocol fees to Robinhood Chain
- Enables v2, v3, and v4 protocol fees on Robinhood Chain.
Please note that this onchain vote enables v2 and v3 fees specifically, while v4 fees will be activated as a part of a separate proposal covering part 1 of the v4 fee activation.
## Implementation Details
Fees on Robinhood Chain will be routed to the TokenJar on that chain. UNI burned on Robinhood Chain is bridged back to Ethereum mainnet and sent to the burn address.
Robinhood Chain is an Arbitrum Orbit chain, so this proposal reuses the pattern from the Arbitrum One activation in proposal 94.
**Governance path.** Same as Arbitrum One: cross-chain governance messages are delivered as retryable tickets through Robinhood Chain's Inbox contract on Ethereum and executed on Robinhood Chain by the L2 alias of the governance Timelock. The aliased Timelock already controls both factories and the v4 PoolManager on Robinhood Chain (it is the v2 factory's feeToSetter and the owner of the v3 factory and the PoolManager), so no ownership migration is required.
**Burn path.** The releaser, ArbitrumOrbitResourceFirepit, is the Arbitrum One firepit generalized for Orbit chains. A searcher pays bridged UNI on Robinhood Chain to claim the TokenJar's accumulated fees, and the contract withdraws that UNI to the burn address on mainnet through the canonical gateway. As on Arbitrum One, the withdrawal finalizes on mainnet after Robinhood Chain's challenge period.
The TokenJar, Releaser, V3OpenFeeAdapter, V4FeeAdapter, and V4FeePolicy will be deployed ahead of the onchain votes, with ownership verified against the aliased Timelock. This post will be updated with those addresses when they've been deployed and a link to the repo containing the contracts and deployment scripts once it has been merged.
Implementation details for the v4 fee system are in the [v4 fee activation temp check](https://gov.uniswap.org/t/temp-check-activate-v4-protocol-fees/26162). v2 and v3 protocol fee levels are the same as on all other chains where fees are live, see breakdown [here](https://developers.uniswap.org/docs/protocols/protocol-fee/concepts/fees#fee-split-table).
## Proposal Spec
If passed, the Robinhood Fee Activation proposal will execute two calls, each creating a retryable ticket in Robinhood Chain's Inbox on Ethereum.
`RH_INBOX.createRetryableTicket(...) x2`
One call will encode:
`V2_FACTORY.setFeeTo(TOKEN_JAR)`
The other will encode:
`V3_FACTORY.setOwner(V3_OPEN_FEE_ADAPTER)`
Once executed on Robinhood Chain, they set the fee collector of UniswapV2Factory to TokenJar and transfer ownership of UniswapV3Factory to V3OpenFeeAdapter.
Robinhood's v4 activation will be included in the V4 Fee Activation (Part 1) proposal described below. Matching the spec of the [v4 fee activation temp check](https://gov.uniswap.org/t/temp-check-activate-v4-protocol-fees/26162), and delivered through the same retryable ticket path, it will encode:
`V4_POOL_MANAGER.setProtocolFeeController(V4_FEE_ADAPTER)`
## Onchain Execution
This Onchain vote covers v2 and v3 fees on Robinhood Chain. v4 fees on Robinhood Chain have been batched in with part 1 of v4 fee activation, as noted above.
2. **V4 Fee Activation (Part 1)**: Ethereum, Base, Robinhood, BNB Chain, Arbitrum, Optimism, Polygon
3. **V4 Fee Activation (Part 2)**: Celo, Soneium, X Layer, World Chain, Zora
All contracts can be found [here](https://github.com/Uniswap/protocol-fees/), and this post will be updated with addresses and explorer links when they have been deployed.
## Next Steps / Timeline
- **Onchain vote begins:** Jul 19, 2026
- **Onchain ends:** Jul 26, 2026
I support this proposal. Updating Uniswap's cross-chain governance infrastructure to current best practices improves long-term security, maintainability, and operational consistency. Migrating away from deprecated messaging systems while simplifying governance across supported networks is a prudent step for the protocol's continued expansion.
# [RFC] Update Crosschain Governance Parameters for Avalanche, MegaETH, Soneium, and X Layer
## Summary
Secure crosschain messaging is an integral part of Uniswap's governance model. Governance votes like protocol fee adjustments are executed by UNI holders on Ethereum Mainnet and must subsequently be relayed to destination chains.
This proposal updates Uniswap's crosschain governance system to accommodate the latest best practices. Specifically, we propose to:
* Transition ownership of the Uniswap v2 and v4 contracts on Soneium and X Layer to CrossChainAccount contracts, which we consider to be the current best practice for executing messages from Ethereum Mainnet on the OP Stack
* Migrate the entire messaging system for the Avalanche and MegaETH deployments from LayerZero v1 (part of which is [being deprecated](https://layerzero.network/blog/ongoing-security-updates)) to Wormhole
Note that because Uniswap v3 on both Soneium and X Layer is owned by the `v3OpenFeeAdapter`, which is owned by the CrossChainAccount, we do not need to change the parameter on v3 on these chains.
---
## Specification
### Current Configuration - Avalanche and MegaETH
Both chains currently use LayerZero v1 for governance messaging. The OmnichainProposalSender contract exists on Ethereum and sends messages to OmnichainGovernanceExecutor on remote chains. Additionally, there exists a second OmnichainGovernanceExecutor on MegaETH which owns the ProxyAdmin contract administering the PositionDescriptor periphery contract responsible for rendering LP positions as NFT's.
| Contract | Chain | Address |
| :---- | :---- | :---- |
| OmnichainProposalSender | Ethereum | [0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc](https://etherscan.io/address/0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc) |
| OmnichainGovernanceExecutor | Avalanche | [0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc](https://snowtrace.io/address/0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc) |
| OmnichainGovernanceExecutor | MegaETH | [0x8819b86ddF592c3aaAa6f9ec7cE1A0f99FC4322c](https://mega.etherscan.io/address/0x8819b86ddF592c3aaAa6f9ec7cE1A0f99FC4322c) |
| OmnichainGovernanceExecutor | MegaETH | [0x51F9629C1e75aF07421E662DBEb2B7dc8deDefd9](https://mega.etherscan.io/address/0x51F9629C1e75aF07421E662DBEb2B7dc8deDefd9) |
### Proposed Configuration - Avalanche and MegaETH
The LayerZero contracts are replaced with the Wormhole bridge infrastructure from [uniswapfoundation/Uniswap-Wormhole-Bridge](https://github.com/uniswapfoundation/Uniswap-Wormhole-Bridge):
**UniswapWormholeSender (Ethereum):** The existing sender contract already deployed on mainnet will be reused — no new deployment required.
**UniswapWormholeReceiver (Avalanche and MegaETH):** Uniswap Labs has deployed new UniswapWormholeReceiver contracts on both chains. This proposal will authorize them as the trusted governance executors for each chain. Additionally, the ProxyAdmin owned by the second OmnichainGovernanceExecutor will be unified with under the authority of the UniswapWormholeReceiver on MegaETH.
| Contract | Chain | Address |
| :---- | :---- | :---- |
| UniswapWormholeSender | Ethereum | [0xf5F4496219F31CDCBa6130B5402873624585615a](https://etherscan.io/address/0xf5F4496219F31CDCBa6130B5402873624585615a) |
| UniswapWormholeReceiver | Avalanche | [0x47eB0Cf11a1626462Da3C830bCDe64c3F582B5a6](https://snowtrace.io/address/0x47eB0Cf11a1626462Da3C830bCDe64c3F582B5a6) |
| UniswapWormholeReceiver | MegaETH | [0xa107580F73BD797Bd8b87Ff24e98346D99F93DdB](https://mega.etherscan.io/address/0xa107580F73BD797Bd8b87Ff24e98346D99F93DdB) |
For a detailed discussion of how Wormhole works, please see [this report](https://uniswap.notion.site/Assessment-dac583c6db1240c7b9d294afd7f18035) by the Uniswap Foundation's Bridge Assessment Committee.
### Current Configuration - Soneium and X Layer
On both chains, the UniswapV2Factory's feeToSetter parameter and the v4 PoolManager's owner parameter are configured as the mainnet Timelock's alias address.
| Account | Chain | Address |
| :---- | :---- | :---- |
| Alias Address | X Layer | [0x2BAD8182C09F50c8318d769245beA52C32Be46CD](https://www.oklink.com/x-layer/evm/address/0x2bad8182c09f50c8318d769245bea52c32be46cd) |
| Alias Address | Soneium | [0x2BAD8182C09F50c8318d769245beA52C32Be46CD](https://soneium.blockscout.com/address/0x2BAD8182C09F50c8318d769245beA52C32Be46CD) |
### Proposed Configuration - Soneium and X Layer
This proposal will change those parameters to a CrossChainAccount contract deployed by Uniswap Labs.
| Contract | Chain | Address |
| :---- | :---- | :---- |
| CrossChainAccount | X Layer | [0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7](https://www.oklink.com/x-layer/evm/address/0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7) |
| CrossChainAccount | Soneium | [0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7](https://soneium.blockscout.com/address/0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7?tab=contract) |
### Onchain Proposal Spec
**Pre-proposal** (already completed by Uniswap Labs):
* Deploy `UniswapWormholeReceiver` on Avalanche C-Chain, configured with the Wormhole Core Bridge address for Avalanche and the address of the existing UniswapWormholeSender.
* Deploy `UniswapWormholeReceiver` on MegaETH, configured with the Wormhole Core Bridge address for MegaETH and the address of the existing UniswapWormholeSender.
* Deploy `CrossChainAccount` contracts on Soneium and X Layer
**In this proposal** (executed if the vote passes):
Execute nine actions:
1. (Ethereum) Set Layer Zero "trusted remote" to the OmnichainGovernanceExecutor on MegaETH
2. (MegaETH) Transfer ownership of the protocol from OmnichainGovernanceExecutor to UniswapWormholeReceiver
3. (Avalanche) Transfer ownership of the protocol from OmnichainGovernanceExecutor to UniswapWormholeReceiver
4. (Soneium) Transfer V2 ownership from the aliased Timelock to CrossChainAccount
5. (Soneium) Transfer V4 ownership from the aliased Timelock to CrossChainAccount
6. (XLayer) Transfer V2 ownership from aliased Timelock to CrossChainAccount
7. (XLayer) Transfer V4 ownership from the aliased Timelock to CrossChainAccount
8. (Ethereum) Set Layer Zero "trusted remote" to the second OmnichainGovernanceExecutor on MegaETH
9. (MegaETH) Transfer ProxyAdmin ownership from the second OmnichainGovernanceExecutor to UniswapWormholeReceiver
Notable Implementation Details:
Regarding MegaETH "trusted remote" configurations: The OmnichainProposalSender on Ethereum must be configured to send messages to the OmnichainGovernanceExecutor on MegaETH, but not the OmnichainGovernanceExecutor on Avalanche. This is due to our OmnichainProposalSender's configuration on initial deployment. The "trusted remote" is Layer Zero's means of defining which sender contracts may interact with which receiver contracts.
Regarding ProxyAdmin: There exists two ProxyAdmin contracts per chain, one for the NonfungiblePositionDescriptor (V3 NFT renderer) and one for the PositionDescriptor (V4 NFT renderer). The ProxyAdmin of the V3 descriptor is owned a different OmnichainGovernanceExecutor than the OmnichainGovernanceExecutor which owns the rest of the protocol (including the V4 descriptor). We are transferring ownership of all of them to the same WormholeReceiver, which necessitates two separate "setTrustedRemote" actions (one for each governance executor) and two separate ownership transfer actions.
Regarding CrossChainAccount: The low level OP-stack chain bridge uses OptimismPortal2. In short, OptimismPortal2's internal details means the protocol on Soneium and X Layer are owned by an "aliased" form of the Timelock address on Ethereum; this alias is derived from adding a standard offset to the Ethereum address. This is an unintuitive system and increases user-error in ownership transitions, so we are migrating to the higher level of abstraction defined by the CrosChainAccount system. This ensures the protocol on Soneium and X Layer are owned by a concrete contract with limits and authority checks from the messages bridged from Ethereum. We already use this system on other OP-stack chains, so this is to update more chains to use it as well.
---
## Next Steps / Timeline
* **RFC:** Jun 26, 2026
* **Snapshot:** ~1 week after RFC
* **Onchain vote:** Following Snapshot, per standard governance cadence
---
## Supporting Documents
* [Uniswap Foundation Bridge Assessment Report](https://uniswap.notion.site/Bridge-Assessment-Report-0c8477afadce425abac9c0bd175ca382)
* [Uniswap-Wormhole-Bridge GitHub](https://github.com/uniswapfoundation/Uniswap-Wormhole-Bridge)
* [LayerZero v1 deprecation announcement](https://layerzero.network/blog/ongoing-security-updates)
* [Original Avalanche deployment proposal](https://gov.uniswap.org/t/deploy-uniswap-v3-on-avalanche/20587)
Voting FOR is the logical choice because this proposal directly expands Uniswap's revenue-to-burn pipeline to highly active networks like BNB Chain, Polygon, and Celo. By automating protocol fee collection and routing it into the cross-chain token burn mechanism, it actively reduces the circulating supply of UNI. Supporting it scales the token's deflationary design and ensures consistent protocol infrastructure across all major multi-chain deployments.
I am voting yes on this proposal to return the 12.5 million delegated UNI tokens from the Franchiser contracts back to the Governance Timelock treasury. While these initial treasury delegations were necessary to secure quorum during a period of low participation in 2022 and 2023, the Uniswap governance landscape has matured significantly, with organic voter turnout now consistently exceeding quorum requirements. Recalling these tokens successfully fixes the structural misalignment between voting power and economic exposure, ensuring the protocol's governance remains decentralized, secure, and driven by active stakeholders.
Supporting this proposal. The original franchiser delegations helped bootstrap governance participation, but the current delegate ecosystem is now mature and decentralized enough to sustain quorum organically. Returning these UNI to the timelock improves governance legitimacy and reduces structural misalignment between voting power and economic exposure.
Supportive overall. Would appreciate continued transparency on TokenJar flows, burn efficiency, and long-term governance oversight of cross-chain fee operations.
# Return 12.5M Delegated Tokens to the Governance Timelock
## Background & Motivation
These UNI were delegated from the treasury in 2022 and 2023 – 2.5M to the Uniswap Foundation and 10M to a group of active delegates - during periods of low governance participation. The delegations aimed to establish an active delegate base when quorum faced risks.
The governance landscape has transformed significantly. Token holders actively delegate voting power, and since DUNI's establishment, passed proposals have averaged roughly 75 million votes in turnout, exceeding quorum by approximately 88%. Over 50 delegates now hold more than 1M UNI in voting power.
Undelegating these tokens addresses potential misalignment created by the Franchiser mechanism itself. While selected delegates participated actively in governance, the Franchiser didn't ensure structural alignment between voting power and economic exposure. This misalignment should not persist when the original implementation rationale no longer applies.
## Specification
This proposal invokes `recallMany` on the FranchiserFactory contract (0xf754A7E347F81cFdc70AF9FbCCe9Df3D826360FA) to retrieve all UNI currently delegated through the Franchiser system, returning the recalled tokens to the Governance Timelock (0x1a9C8182C09F50C8318d769245beA52c32BE35BC).
Eight Franchiser delegations are targeted for undelegation, totaling ~12.5M UNI:
| **Recipient** | **Address** | **Votes** |
| --- | --- | --- |
| Uniswap Foundation | [`0xA37131410A76791f4A0210e91EDD554d85aFb4d4`](https://etherscan.io/address/0xA37131410A76791f4A0210e91EDD554d85aFb4d4) | 2,500,001.19 |
| Anode | [`0xECC2a9240268BC7a26386ecB49E1Befca2706AC9`](https://etherscan.io/address/0xECC2a9240268BC7a26386ecB49E1Befca2706AC9) | 2,499,858 |
| Axia Network | [`0xE93D59CC0bcECFD4ac204827eF67c5266079E2b5`](https://etherscan.io/address/0xE93D59CC0bcECFD4ac204827eF67c5266079E2b5) | 2.25M |
| PGov | [`0x3fb19771947072629c8eee7995a2ef23b72d4c8a`](https://etherscan.io/address/0x3fb19771947072629c8eee7995a2ef23b72d4c8a) | 2.25M |
| Wintermute | [`0xB933AEe47C438f22DE0747D57fc239FE37878Dd1`](https://etherscan.io/address/0xB933AEe47C438f22DE0747D57fc239FE37878Dd1) | 1.9M |
| Keyrock | [`0x1855f41B8A86e701E33199DE7C25d3e3830698ba`](https://etherscan.io/address/0x1855f41B8A86e701E33199DE7C25d3e3830698ba) | 494K |
| KPK | [`0x8787FC2De4De95c53e5E3a4e5459247D9773ea52`](https://etherscan.io/address/0x8787FC2De4De95c53e5E3a4e5459247D9773ea52) | 453K |
| Atiselsts.eth | [`0xAac35d953Ef23aE2E61a866ab93deA6eC0050bcD`](https://etherscan.io/address/0xAac35d953Ef23aE2E61a866ab93deA6eC0050bcD) | 154K |
The UF Franchiser has accumulated ~1.19 UNI of unrelated inbound transfers from third parties since it was funded. `recall` always sweeps the full balance (the Franchiser contract has no partial-recall option), so those stray amounts will return to the Treasury along with the original 2.5M.
# Protocol Fee Expansion: Vote 3
## Proposal Spec
If this proposal passes, it will execute three actions, each of which has multiple inner calls.
On BNB Chain and Polygon, the actions will execute the following transactions:
```
/// Set the recipient of V2 protocol fees to the TokenJar
V2_FACTORY.setFeeTo(address(tokenJar));
/// Set the owner of the V3 Factory to the V3OpenFeeAdapter
V3_FACTORY.setOwner(address(v3OpenFeeAdapter));
```
On Celo, the action will execute the following transactions:
```
/// Set the recipient of V2 protocol fees to the TokenJar
V2_FACTORY.setFeeTo(address(tokenJar));
/// Transfer feeToSetter role from Wormhole to the CrossChainAccount
V2_FACTORY.setFeeToSetter(address(crossChainAccount));
/// Set the owner of the V3 Factory to the V3OpenFeeAdapter
V3_FACTORY.setOwner(address(v3OpenFeeAdapter));
/// Transfer ownership of the V4 PoolManager to the CrossChainAccount
POOL_MANAGER.transferOwnership(address(crossChainAccount));
```
### Relevant Addresses
**Celo**
| **Contract** | **Network** | **Address** |
| --- | --- | --- |
| TokenJar | Celo | [`0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B`](https://celoscan.io/address/0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B) |
| V3OpenFeeAdapter | Celo | [`0xB9952C01830306ea2fAAe1505f6539BD260Bfc48`](https://celoscan.io/address/0xB9952C01830306ea2fAAe1505f6539BD260Bfc48) |
| UniswapV3Factory | Celo | [`0xAfE208a311B21f13EF87E33A90049fC17A7acDEc`](https://celoscan.io/address/0xAfE208a311B21f13EF87E33A90049fC17A7acDEc) |
| UniswapV2Factory | Celo | [`0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7`](https://celoscan.io/address/0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7) |
| PoolManager | Celo | [`0x288dc841A52FCA2707c6947B3A777c5E56cd87BC`](https://celoscan.io/address/0x288dc841A52FCA2707c6947B3A777c5E56cd87BC) |
| UniswapWormholeMessageReceiver | Celo | [`0x0Eb863541278308c3A64F8E908BC646e27BFD071`](https://celoscan.io/address/0x0Eb863541278308c3A64F8E908BC646e27BFD071) |
| Celo CrossChainAccount | Celo | [`0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7`](https://celoscan.io/address/0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7) |
| Wormhole Sender | Ethereum | [`0xf5F4496219F31CDCBa6130B5402873624585615a`](https://etherscan.io/address/0xf5F4496219F31CDCBa6130B5402873624585615a) |
**BNB Chain**
| **Contract** | **Network** | **Address** |
| --- | --- | --- |
| TokenJar | BNB Chain | [`0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A`](https://bscscan.com/address/0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A) |
| V3OpenFeeAdapter | BNB Chain | [`0x3F07F08b45912dCd6691C5B9412975D5113B2910`](https://bscscan.com/address/0x3F07F08b45912dCd6691C5B9412975D5113B2910) |
| UniswapV3Factory | BNB Chain | [`0xdB1d10011AD0Ff90774D0C6Bb92e5C5c8b4461F7`](https://bscscan.com/address/0xdB1d10011AD0Ff90774D0C6Bb92e5C5c8b4461F7) |
| UniswapV2Factory | BNB Chain | [`0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6`](https://bscscan.com/address/0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6) |
| UniswapWormholeMessageReceiver | BNB Chain | [`0x341c1511141022cf8eE20824Ae0fFA3491F1302b`](https://bscscan.com/address/0x341c1511141022cf8eE20824Ae0fFA3491F1302b) |
| Wormhole Sender | Ethereum | [`0xf5F4496219F31CDCBa6130B5402873624585615a`](https://etherscan.io/address/0xf5F4496219F31CDCBa6130B5402873624585615a) |
**Polygon**
| **Contract** | **Network** | **Address** |
| --- | --- | --- |
| TokenJar | Polygon | [`0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A`](https://polygonscan.com/address/0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A) |
| V3OpenFeeAdapter | Polygon | [`0x3F07F08b45912dCd6691C5B9412975D5113B2910`](https://polygonscan.com/address/0x3F07F08b45912dCd6691C5B9412975D5113B2910) |
| UniswapV3Factory | Polygon | [`0x1F98431c8aD98523631AE4a59f267346ea31F984`](https://polygonscan.com/address/0x1F98431c8aD98523631AE4a59f267346ea31F984) |
| UniswapV2Factory | Polygon | [`0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C`](https://polygonscan.com/address/0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C) |
| Ethereum Proxy | Polygon | [`0x8a1B966aC46F42275860f905dbC75EfBfDC12374`](https://polygonscan.com/address/0x8a1B966aC46F42275860f905dbC75EfBfDC12374) |
| Polygon Fx Root | Ethereum | [`0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2`](https://etherscan.io/address/0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2) |
## Proposal
This proposal continues the protocol fee rollout, following proposals [#93](https://vote.uniswapfoundation.org/proposals/93), [#94](https://vote.uniswapfoundation.org/proposals/94), and [#95](https://vote.uniswapfoundation.org/proposals/95). It uses the expedited governance process [approved](https://gov.uniswap.org/t/unification-proposal/25881#p-57882-protocol-fee-rollout-4) in UNIfication, where fee parameter update proposals can bypass the RFC stage and go directly to a five-day Snapshot followed by an onchain vote.
Since protocol fees went live on Ethereum mainnet in late December, the rollout has extended to 73 additional chains (Arbitrum, Base, OP Mainnet, Soneium, X Layer, Worldchain, and Zora). The burn system is working as designed, with fees accumulating in TokenJars across chains. From there, searchers claim them in exchange for burning UNI by bridging it back to mainnet and sending it to the burn address.
This proposal:
* Extends the infrastructure for collecting and burning protocol fees to BNB Chain and Polygon
* Enables v2 and v3 protocol fees on these chains
* Completes Celo's fee activation through a corrected cross-chain governance path, which was approved in a previous [proposal](https://vote.uniswapfoundation.org/proposals/94) but did not execute due to a configuration error
## Implementation Details
Fees on each chain will be routed to the TokenJar on that respective chain. UNI burned on these chains is bridged back to Ethereum mainnet and sent to the burn address.
Celo uses the [same architecture](https://github.com/Uniswap/protocol-fees/blob/main/src/releasers/OptimismBridgedResourceFirepit.sol) as other OP-stack chains. On BNB and Polygon, we make use of Wormhole’s Native Token Transfer (NTT) mechanism for multichain token management. Details on our implementation can be found [here](https://github.com/Uniswap/protocol-fees/blob/main/script/proposal-4/Index.md).
Protocol fee levels are the same on all other chains where fees are live, see breakdown [here](https://developers.uniswap.org/docs/protocols/protocol-fee/concepts/fees#fee-split-table).
I’m voting For this proposal.
The initial fee rollout on mainnet has been live for a while now, and we haven’t seen the kind of liquidity flight that some people were worried about. TVL has held up, volume is strong, and the burn mechanism is working as intended. Expanding fees to L2s where more activity is happening just feels like the logical next step.
I also support moving to the tier-based v3 fee model. Managing fees pool-by-pool doesn’t scale, and having a consistent structure across tiers makes governance simpler and more predictable. Governance still retains override power, which is an important safeguard.
At this stage, Uniswap isn’t an experiment anymore — it’s core infrastructure. Turning on protocol fees across chains aligns incentives, strengthens UNI, and doesn’t fundamentally change how LPs or traders use the protocol.
This feels like a measured evolution, not an aggressive shift. Happy to support it.
# Protocol Fee Expansion: Vote 2
## Proposal Spec
If this proposal passes, it will execute ten transactions:
```
/// Enable fees on Soneium, XLayer, Celo, Woldchain, and Zora. For each chain:
/// Set the owner of the V3 Factory to the V3OpenFeeAdapter
V3_FACTORY.setOwner(address(v3OpenFeeAdapter));
/// Set the recipient of V2 protocol fees to the TokenJar
V2_FACTORY.setFeeTo(address(tokenJar));
```
Because these transactions are crosschain, governance front ends may not decode them correctly. We recommend reviewing the [Seatbelt simulation report](https://github.com/uniswapfoundation/governance-seatbelt/actions) to confirm their validity. Three other things to note:
- Soneium and XLayer deployments are owned by DUNI's alias address on those chains. Celo, Worldchain, and Zora deployments are owned by CrossChainAccount contracts owned by DUNI. Standardizing ownership across chains will be addressed in a future governance proposal.
- On Celo, Uniswap v2 and v3 admin roles are being transferred from Wormhole to a DUNI-owned CrossChainAccount in proposal 94, which will execute prior to this proposal if passed. Because this proposal uses that CrossChainAccount, simulations currently fail.
- Tenderly, a dependency for these simulations, does not support Zora so those calls cannot be simulated.
### Relevant Addresses
**Soneium**
| **Contract** | **Address** |
| --- | --- |
| TokenJar | [`0x85aeb792b94a9d79741002FC871423Ec5dAD29e9`](https://soneium.blockscout.com/address/0x85aeb792b94a9d79741002FC871423Ec5dAD29e9) |
| Releaser (OptimismBridgedResourceFirepit) | [`0xc9CC50A75cE2a5f88fa77B43e3b050480c731b6e`](https://soneium.blockscout.com/address/0xc9CC50A75cE2a5f88fa77B43e3b050480c731b6e) |
| V3OpenFeeAdapter | [`0x47Cf920815344Fd684A48BBEFcbfbed9C7AE09CF`](https://soneium.blockscout.com/address/0x47Cf920815344Fd684A48BBEFcbfbed9C7AE09CF) |
| UniswapV3Factory | [`0x42aE7Ec7ff020412639d443E245D936429Fbe717`](https://soneium.blockscout.com/address/0x42aE7Ec7ff020412639d443E245D936429Fbe717) |
| UniswapV2Factory | [`0x97FeBbC2AdBD5644ba22736E962564B23F5828CE`](https://soneium.blockscout.com/address/0x97FeBbC2AdBD5644ba22736E962564B23F5828CE) |
| Mainnet Bridge | [`0x88e529A6ccd302c948689Cd5156C83D4614FAE92`](https://etherscan.io/address/0x88e529A6ccd302c948689Cd5156C83D4614FAE92) |
**XLayer**
| **Contract** | **Address** |
| --- | --- |
| TokenJar | [`0x8Dd8B6D56e4a4A158EDbBfE7f2f703B8FFC1a754`](https://www.oklink.com/x-layer/address/0x8dd8b6d56e4a4a158edbbfe7f2f703b8ffc1a754/contract) |
| Releaser (OptimismBridgedResourceFirepit) | [`0xe122E231cb52aea99690963Fd73E91e33E97468f`](https://www.oklink.com/xlayer/address/0xe122E231cb52aea99690963Fd73E91e33E97468f) |
| V3OpenFeeAdapter | [`0x6A88EF2e6511CAFfE2D006e260e7A5d1E7D4d7D7`](https://www.oklink.com/x-layer/address/0x6a88ef2e6511caffe2d006e260e7a5d1e7d4d7d7/contract) |
| UniswapV3Factory | [`0x4B2ab38DBF28D31D467aA8993f6c2585981D6804`](https://www.oklink.com/x-layer/address/0x4b2ab38dbf28d31d467aa8993f6c2585981d6804/contract) |
| UniswapV2Factory | [`0xDf38F24fE153761634Be942F9d859f3DBA857E95`](https://www.oklink.com/x-layer/address/0xdf38f24fe153761634be942f9d859f3dba857e95) |
| Mainnet Bridge | [`0x64057ad1DdAc804d0D26A7275b193D9DACa19993`](https://etherscan.io/address/0x64057ad1DdAc804d0D26A7275b193D9DACa19993#code) |
**Celo**
| **Contract** | **Address** |
| --- | --- |
| TokenJar | [`0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B`](https://celoscan.io/address/0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B#code) |
| Releaser (OptimismBridgedResourceFirepit) | [`0x2758FbaA228D7d3c41dD139F47dab1a27bF9bc25`](https://celoscan.io/address/0x2758FbaA228D7d3c41dD139F47dab1a27bF9bc25) |
| V3OpenFeeAdapter | [`0xB9952C01830306ea2fAAe1505f6539BD260Bfc48`](https://celoscan.io/address/0xB9952C01830306ea2fAAe1505f6539BD260Bfc48) |
| UniswapV3Factory | [`0xAfE208a311B21f13EF87E33A90049fC17A7acDEc`](https://celoscan.io/address/0xafe208a311b21f13ef87e33a90049fc17a7acdec) |
| UniswapV2Factory | [`0x79a530c8e2fA8748B7B40dd3629C0520c2cCf03f`](https://celoscan.io/address/0x79a530c8e2fA8748B7B40dd3629C0520c2cCf03f#code) |
| Mainnet Bridge | [`0x1AC1181fc4e4F877963680587AEAa2C90D7EbB95`](https://etherscan.io/address/0x1AC1181fc4e4F877963680587AEAa2C90D7EbB95) |
| Celo CrossChainAccount | [`0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7`](https://celoscan.io/address/0x044aaf330d7fd6ae683eec5c1c1d1fff5196b6b7) |
**Worldchain**
| **Contract** | **Address** |
| --- | --- |
| TokenJar | [`0xbDb82c2dE7D8748A3e499e771604ef8ef8544918`](https://worldscan.org/address/0xbDb82c2dE7D8748A3e499e771604ef8ef8544918#code) |
| Releaser (OptimismBridgedResourceFirepit) | [`0xbDb82c2dE7D8748A3e499e771604ef8ef8544918`](https://worldscan.org/address/0xbDb82c2dE7D8748A3e499e771604ef8ef8544918) |
| V3OpenFeeAdapter | [`0x1CE9d4DfB474Ef9ea7dc0e804a333202e40d6201`](https://worldscan.org/address/0x1CE9d4DfB474Ef9ea7dc0e804a333202e40d6201#code) |
| UniswapV3Factory | [`0x7a5028BDa40e7B173C278C5342087826455ea25a`](https://worldscan.org/address/0x7a5028bda40e7b173c278c5342087826455ea25a#code) |
| UniswapV2Factory | [`0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f`](https://worldscan.org/address/0x5c69bee701ef814a2b6a3edd4b1652cb9cc5aa6f#code) |
| Mainnet Bridge | [`0xf931a81D18B1766d15695ffc7c1920a62b7e710a`](https://etherscan.io/address/0xf931a81D18B1766d15695ffc7c1920a62b7e710a) |
| CrossChainAccount | [`0xcb2436774C3e191c85056d248EF4260ce5f27A9D`](https://worldscan.org/address/0xcb2436774c3e191c85056d248ef4260ce5f27a9d) |
**Zora**
| **Contract** | **Address** |
| --- | --- |
| TokenJar | [`0x4753C137002D802f45302b118E265c41140e73C2`](https://explorer.zora.energy/address/0x4753C137002D802f45302b118E265c41140e73C2) |
| Releaser (OptimismBridgedResourceFirepit) | [`0x2f98eD4D04e633169FbC941BFCc54E785853b143`](https://explorer.zora.energy/address/0x2f98eD4D04e633169FbC941BFCc54E785853b143) |
| V3OpenFeeAdapter | [`0xbfc49b47637a4DC9b7B8dE8E71BF41E519103B95`](https://explorer.zora.energy/address/0xbfc49b47637a4DC9b7B8dE8E71BF41E519103B95) |
| UniswapV3Factory | [`0x7145F8aeef1f6510E92164038E1B6F8cB2c42Cbb`](https://explorer.zora.energy/address/0x7145F8aeef1f6510E92164038E1B6F8cB2c42Cbb) |
| UniswapV2Factory | [`0x0F797dC7efaEA995bB916f268D919d0a1950eE3C`](https://explorer.zora.energy/address/0x0F797dC7efaEA995bB916f268D919d0a1950eE3C) |
| Mainnet Bridge | [`0xdC40a14d9abd6F410226f1E6de71aE03441ca506`](https://etherscan.io/address/0xdc40a14d9abd6f410226f1e6de71ae03441ca506) |
| CrossChainAccount | [`0x36eEC182D0B24Df3DC23115D64DB521A93D5154f`](https://explorer.zora.energy/address/0x36eEC182D0B24Df3DC23115D64DB521A93D5154f) |
## Proposal
*This is the first proposal to use the new governance process [approved](https://gov.uniswap.org/t/unification-proposal/25881#p-57882-protocol-fee-rollout-4) in UNIfication. The new process only applies to fee parameter updates, where proposals can bypass the RFC stage and go directly to a five-day Snapshot followed by an onchain vote. This allows for faster updates to protocol fees, while retaining the security of onchain governance.*
Snapshot vote [here](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x0242a914c60945d25873d2a98c6abd9f69cb889c6616e27f3c0ab759f9e8d783).
Since UNIfication went live in late December we have been monitoring protocol fees, which were rolled out gradually to ensure protocol health. This started with v2 and select v3 pools on Ethereum mainnet. This rollout has gone well, with market-adjusted TVL [up](https://defillama.com/protocol/uniswap?fees=false&events=false&denomination=ETH) on Ethereum mainnet since December. The burn system is working as expected, permissionlessly converting fees in [many different tokens](https://dune.com/queries/6711845) into UNI burns.
Now, we propose to:
- Expand protocol fees on v2 and v3 to Arbitrum, Base, Celo, OP Mainnet, Soneium, X Layer, Worldchain, and Zora
- Enable protocol fees on all v3 pools via a new tier-based [v3OpenFeeAdapter](https://github.com/Uniswap/protocol-fees/blob/main/src/feeAdapters/V3OpenFeeAdapter.sol) on mainnet and the above L2s
### **Implementation Details**
**Expand protocol fees to L2s and burn UNI on mainnet**
This proposal introduces v2 and v3 protocol fees on eight chains. Fees on each chain will be routed to the TokenJar on that respective chain.
UNI burned on L2s doesn't stay on L2s - it is bridged back to mainnet and sent to 0xdead. This uses the same infrastructure used for burning Unichain sequencer fees ([OptimismBridgedResourceFirepit](https://github.com/Uniswap/protocol-fees/blob/main/src/releasers/OptimismBridgedResourceFirepit.sol) for OP Stack chains, and [ArbitrumBridgedResourceFirepit](https://github.com/Uniswap/protocol-fees/blob/main/src/releasers/ArbitrumBridgedResourceFirepit.sol) for Arbitrum).
**Enable fees on all v3 pools**
The current v3FeeAdapter manages protocol fees pool by pool and governance maintains a list of individual pools and their fee levels. Today, those pools account for a significant majority of v3 volume on Ethereum mainnet.
v3OpenFeeAdapter replaces this with a tier-based system. Protocol fees are set uniformly across all pools sharing the same LP fee tier. For example, all 1bps LP fee pools could have protocol fees set to 25%. Any pool automatically gets the default protocol fee for its tier, no governance action is needed. This means if this proposal passes, protocol fees will be active on every v3 pool. Governance retains the ability to override fees on individual pools.
### **Governance Process**
Please note that because of GovernorBravo's limit of 10 actions per proposal, there will be two separate onchain votes posted in parallel. One proposal will include the change to mainnet's fee controller and turn on fees on Base, OP Mainnet, and Arbitrum, the other will turn on fees on Celo, Soneium, Worldchain, X Layer, and Zora.
# Protocol Fee Expansion: Vote 1
## Proposal Spec
If this proposal passes, it will execute ten transactions:
```
/// Transition to v3OpenFeeAdapter on Mainnet
/// Change the owner on UniswapV3Factory to v3OpenFeeAdapter
V3_FEE_ADAPTER.setFactoryOwner(address(v3OpenFeeAdapter));
/// Enable fees on Arbitrum, Base, and OP Mainnet. For each chain:
/// Set the owner of the V3 Factory to the V3OpenFeeAdapter
V3_FACTORY.setOwner(address(v3OpenFeeAdapter));
/// Set the recipient of V2 protocol fees to the TokenJar
V2_FACTORY.setFeeTo(address(tokenJar));
/// Transition to CrossChainAccount ownership on Celo
/// Transfer v2 setFeeToSetter role
V2_FACTORY.setFeeToSetter(CrossChainAccount)
/// Transfer UniswapV3Factory owner role
V3_FACTORY.setOwner(CrossChainAccount)
// Transfer Uniswap v4 PoolManager owner role
POOL_MANAGER.transferOwnership(CrossChainAccount)
```
Because these transactions are crosschain, governance front ends may not decode them correctly. We recommend reviewing the [Seatbelt simulation report](https://github.com/uniswapfoundation/governance-seatbelt/actions) to confirm their validity.
### Relevant Addresses
**Mainnet**
| **Contract** | **Address** |
| --- | --- |
| V3OpenFeeAdapter | [`0x3e40DB80450f025b01E45c58b0aF763C7A29a8bd`](https://etherscan.io/address/0x3e40DB80450f025b01E45c58b0aF763C7A29a8bd) |
| V3FeeAdapter | [`0x5E74C9f42EEd283bFf3744fBD1889d398d40867d`](https://etherscan.io/address/0x5E74C9f42EEd283bFf3744fBD1889d398d40867d) |
**Arbitrum**
| **Contract** | **Address** |
| --- | --- |
| TokenJar | [`0x95E337C5B155385945D407f5396387D0c2a3A263`](https://arbiscan.io/address/0x95E337C5B155385945D407f5396387D0c2a3A263) |
| Releaser (ArbitrumBridgedResourceFirepit) | [`0xB8018422bcE25D82E70cB98FdA96a4f502D89427`](https://arbiscan.io/address/0xB8018422bcE25D82E70cB98FdA96a4f502D89427) |
| V3OpenFeeAdapter | [`0xFF7aD5dA31fECdC678796c88B05926dB896b0699`](https://arbiscan.io/address/0xFF7aD5dA31fECdC678796c88B05926dB896b0699) |
| UniswapV3Factory | [`0x1F98431c8aD98523631AE4a59f267346ea31F984`](https://arbiscan.io/address/0x1F98431c8aD98523631AE4a59f267346ea31F984) |
| UniswapV2Factory | [`0xf1D7CC64Fb4452F05c498126312eBE29f30Fbcf9`](https://arbiscan.io/address/0xf1D7CC64Fb4452F05c498126312eBE29f30Fbcf9) |
**OP Mainnet**
| **Contract** | **Address** |
| --- | --- |
| TokenJar | [`0xb13285DF724ea75f3f1E9912010B7e491dCd5EE3`](https://optimistic.etherscan.io/address/0xb13285DF724ea75f3f1E9912010B7e491dCd5EE3) |
| Releaser (OptimismBridgedResourceFirepit) | [`0x94460443Ca27FFC1baeCa61165fde18346C91AbD`](https://optimistic.etherscan.io/address/0x94460443Ca27FFC1baeCa61165fde18346C91AbD) |
| V3OpenFeeAdapter | [`0xec23Cf5A1db3dcC6595385D28B2a4D9B52503Be4`](https://optimistic.etherscan.io/address/0xec23Cf5A1db3dcC6595385D28B2a4D9B52503Be4) |
| UniswapV3Factory | [`0x1F98431c8aD98523631AE4a59f267346ea31F984`](https://optimistic.etherscan.io/address/0x1F98431c8aD98523631AE4a59f267346ea31F984) |
| UniswapV2Factory | [`0x0c3c1c532F1e39EdF36BE9Fe0bE1410313E074Bf`](https://optimistic.etherscan.io/address/0x0c3c1c532F1e39EdF36BE9Fe0bE1410313E074Bf#readContract) |
**Base**
| **Contract** | **Address** |
| --- | --- |
| TokenJar | [`0x9bD25e67bF390437C8fAF480AC735a27BcF6168c`](https://basescan.org/address/0x9bD25e67bF390437C8fAF480AC735a27BcF6168c) |
| Releaser (OptimismBridgedResourceFirepit) | [`0xFf77c0ED0B6b13A20446969107E5867abc46f53a`](https://basescan.org/address/0xFf77c0ED0B6b13A20446969107E5867abc46f53a) |
| V3OpenFeeAdapter | [`0xaBEA76658b205696d49B5F91b2a03536cB8A3bE1`](https://basescan.org/address/0xaBEA76658b205696d49B5F91b2a03536cB8A3bE1) |
| UniswapV3Factory | [`0x33128a8fC17869897dcE68Ed026d694621f6FDfD`](https://basescan.org/address/0x33128a8fC17869897dcE68Ed026d694621f6FDfD) |
| UniswapV2Factory | [`0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6`](https://basescan.org/address/0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6) |
**Celo**
| **Contract** | **Address** |
| --- | --- |
| CrossChainAccount | [`0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7`](https://celoscan.io/address/0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7) |
| UniswapV3Factory | [`0xAfE208a311B21f13EF87E33A90049fC17A7acDEc`](https://celoscan.io/address/0xAfE208a311B21f13EF87E33A90049fC17A7acDEc) |
| UniswapV2Factory | [`0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7`](https://celoscan.io/address/0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7#code) |
## Proposal
*This is the first proposal to use the new governance process [approved](https://gov.uniswap.org/t/unification-proposal/25881#p-57882-protocol-fee-rollout-4) in UNIfication. The new process only applies to fee parameter updates, where proposals can bypass the RFC stage and go directly to a five-day Snapshot followed by an onchain vote. This allows for faster updates to protocol fees, while retaining the security of onchain governance.*
Snapshot vote [here](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x0242a914c60945d25873d2a98c6abd9f69cb889c6616e27f3c0ab759f9e8d783).
Since UNIfication went live in late December we have been monitoring protocol fees, which were rolled out gradually to ensure protocol health. This started with v2 and select v3 pools on Ethereum mainnet. This rollout has gone well, with market-adjusted TVL [up](https://defillama.com/protocol/uniswap?fees=false&events=false&denomination=ETH) on Ethereum mainnet since December. The burn system is working as expected, permissionlessly converting fees in [many different tokens](https://dune.com/queries/6711845) into UNI burns.
Now, we propose to:
- Expand protocol fees on v2 and v3 to Arbitrum, Base, Celo, OP Mainnet, Soneium, X Layer, Worldchain, and Zora
- Enable protocol fees on all v3 pools via a new tier-based [v3OpenFeeAdapter](https://github.com/Uniswap/protocol-fees/blob/main/src/feeAdapters/V3OpenFeeAdapter.sol) on mainnet and the above L2s
### **Implementation Details**
**Expand protocol fees to L2s and burn UNI on mainnet**
This proposal introduces v2 and v3 protocol fees on eight chains. Fees on each chain will be routed to the TokenJar on that respective chain.
UNI burned on L2s doesn't stay on L2s - it is bridged back to mainnet and sent to 0xdead. This uses the same infrastructure used for burning Unichain sequencer fees ([OptimismBridgedResourceFirepit](https://github.com/Uniswap/protocol-fees/blob/main/src/releasers/OptimismBridgedResourceFirepit.sol) for OP Stack chains, and [ArbitrumBridgedResourceFirepit](https://github.com/Uniswap/protocol-fees/blob/main/src/releasers/ArbitrumBridgedResourceFirepit.sol) for Arbitrum).
**Enable fees on all v3 pools**
The current v3FeeAdapter manages protocol fees pool by pool and governance maintains a list of individual pools and their fee levels. Today, those pools account for a significant majority of v3 volume on Ethereum mainnet.
v3OpenFeeAdapter replaces this with a tier-based system. Protocol fees are set uniformly across all pools sharing the same LP fee tier. For example, all 1bps LP fee pools could have protocol fees set to 25%. Any pool automatically gets the default protocol fee for its tier, no governance action is needed. This means if this proposal passes, protocol fees will be active on every v3 pool. Governance retains the ability to override fees on individual pools.
### **Governance Process**
Please note that because of GovernorBravo’s limit of 10 actions per proposal, there will be two separate onchain votes posted in parallel. One proposal will include the change to mainnet’s fee controller and turn on fees on Base, OP Mainnet, and Arbitrum, the other will turn on fees on Celo, Soneium, Worldchain, X Layer, and Zora.
I’m voting in favor of the Unification proposal. This is a historic moment for Uniswap and a meaningful step forward not only for the protocol, but for the broader DeFi ecosystem. Unification strengthens alignment, clarity, and long-term sustainability, reinforcing Uniswap’s role as core infrastructure for decentralized finance.