This proposal continues the protocol fee rollout, following proposals #92, #93, and #94. It uses the expedited governance process approved 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 nine 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:
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 0xdead.
Celo uses the same architecture as other OP-stack chains. On BNB and Polygon, we make use of Wormhole’s Native Token Transfer (NTT) mechanism for multichain token management. This post will be updated early the week of May 18, 2026 with links to the repository containing these contracts and a full description of our implementation.
Protocol fee levels are the same on all other chains where fees are live, see breakdown here.
If passed, this proposal will execute three actions: one each for Celo, BNB Chain, and Polygon. Each action contains multiple inner calls.
This action sets the fee collector of UniswapV2Factory to TokenJar, transfers ownership of UniswapV2Factory and PoolManager to Optimism CrossChainAccount, and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter.
RELEVANT ADDRESSES:
| Name | Network | Address | Description |
|---|---|---|---|
| V2_FACTORY | Celo | 0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7 | Uniswap V2 Factory |
| V3_FACTORY | Celo | 0xAfE208a311B21f13EF87E33A90049fC17A7acDEc | Uniswap V3 Factory |
| V4_POOL_MANAGER | Celo | 0x288dc841A52FCA2707c6947B3A777c5E56cd87BC | Uniswap V4 Pool Manager |
| TOKEN_JAR | Celo | 0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B | Fee Collector |
| V3_OPEN_FEE_ADAPTER | Celo | 0xB9952C01830306ea2fAAe1505f6539BD260Bfc48 | Uniswap V3 Fee Adapter |
| UNISWAP_WORMHOLE_MESSAGE_RECEIVER | Celo | 0x0Eb863541278308c3A64F8E908BC646e27BFD071 | Governance Owned Wormhole Receiver |
| CROSS_CHAIN_ACCOUNT | Celo | 0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7 | Governance-owned OP Bridge Receiver |
| WORMHOLE_SENDER | Ethereum | 0xf5F4496219F31CDCBa6130B5402873624585615a | Wormhole Sender |
WORMHOLE_SENDER.sendMessage(targets, values, datas, UNISWAP_WORMHOLE_MESSAGE_RECEIVER, CELO_CHAIN_ID)
encodes:
V2_FACTORY.setFeeTo(TOKEN_JAR)
V2_FACTORY.setFeeToSetter(CROSS_CHAIN_ACCOUNT)
V3_FACTORY.setOwner(V3_OPEN_FEE_ADAPTER)
V4_POOL_MANAGER.transferOwnership(CROSS_CHAIN_ACCOUNT)
This action sets the fee collector of UniswapV2Factory to TokenJar and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter.
RELEVANT ADDRESSES:
| Name | Network | Address | Description |
|---|---|---|---|
| V2_FACTORY | BNB Chain | 0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6 | Uniswap V2 Factory |
| V3_FACTORY | BNB Chain | 0xdB1d10011AD0Ff90774D0C6Bb92e5C5c8b4461F7 | Uniswap V3 Factory |
| UNISWAP_WORMHOLE_MESSAGE_RECEIVER | BNB Chain | 0x341c1511141022cf8eE20824Ae0fFA3491F1302b | Governance Owned Wormhole Receiver |
| TOKEN_JAR | BNB Chain | 0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A | Fee Collector |
| V3_OPEN_FEE_ADAPTER | BNB Chain | 0x3F07F08b45912dCd6691C5B9412975D5113B2910 | Uniswap V3 Fee Adapter |
| WORMHOLE_SENDER | Ethereum | 0xf5F4496219F31CDCBa6130B5402873624585615a | Wormhole Sender |
WORMHOLE_SENDER.sendMessage(targets, values, datas, UNISWAP_WORMHOLE_MESSAGE_RECEIVER, BNB_CHAIN_ID)
encodes:
V2_FACTORY.setFeeTo(TOKEN_JAR)
V3_FACTORY.setOwner(V3_OPEN_FEE_ADAPTER)
This action sets the fee collector of UniswapV2Factory to TokenJar and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter.
RELEVANT ADDRESSES:
| Name | Network | Address | Description |
|---|---|---|---|
| V2_FACTORY | Polygon | 0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C | Uniswap V2 Factory |
| V3_FACTORY | Polygon | 0x1F98431c8aD98523631AE4a59f267346ea31F984 | Uniswap V3 Factory |
| ETHEREUM_PROXY | Polygon | 0x8a1B966aC46F42275860f905dbC75EfBfDC12374 | Governance Owned FxChild Receiver |
| TOKEN_JAR | Polygon | 0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A | Fee Collector |
| V3_OPEN_FEE_ADAPTER | Polygon | 0x3F07F08b45912dCd6691C5B9412975D5113B2910 | Uniswap V3 Fee Adapter |
| POLYGON_FX_ROOT | Ethereum | 0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2 | Polygon's Sender (on Ethereum) |
POLYGON_FX_ROOT.sendMessageToChild(ETHEREUM_PROXY, abi.encode(targets, datas, values))
encodes:
V2_FACTORY.setFeeTo(TOKEN_JAR)
V3_FACTORY.setOwner(V3_OPEN_FEE_ADAPTER)
This proposal continues the protocol fee rollout, following proposals #92, #93, and #94. It uses the expedited governance process approved 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 nine 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:
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 0xdead.
Celo uses the same architecture as other OP-stack chains. On BNB and Polygon, we make use of Wormhole’s Native Token Transfer (NTT) mechanism for multichain token management. This post will be updated early the week of May 18, 2026 with links to the repository containing these contracts and a full description of our implementation.
Protocol fee levels are the same on all other chains where fees are live, see breakdown here.
If passed, this proposal will execute three actions: one each for Celo, BNB Chain, and Polygon. Each action contains multiple inner calls.
This action sets the fee collector of UniswapV2Factory to TokenJar, transfers ownership of UniswapV2Factory and PoolManager to Optimism CrossChainAccount, and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter.
RELEVANT ADDRESSES:
| Name | Network | Address | Description |
|---|---|---|---|
| V2_FACTORY | Celo | 0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7 | Uniswap V2 Factory |
| V3_FACTORY | Celo | 0xAfE208a311B21f13EF87E33A90049fC17A7acDEc | Uniswap V3 Factory |
| V4_POOL_MANAGER | Celo | 0x288dc841A52FCA2707c6947B3A777c5E56cd87BC | Uniswap V4 Pool Manager |
| TOKEN_JAR | Celo | 0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B | Fee Collector |
| V3_OPEN_FEE_ADAPTER | Celo | 0xB9952C01830306ea2fAAe1505f6539BD260Bfc48 | Uniswap V3 Fee Adapter |
| UNISWAP_WORMHOLE_MESSAGE_RECEIVER | Celo | 0x0Eb863541278308c3A64F8E908BC646e27BFD071 | Governance Owned Wormhole Receiver |
| CROSS_CHAIN_ACCOUNT | Celo | 0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7 | Governance-owned OP Bridge Receiver |
| WORMHOLE_SENDER | Ethereum | 0xf5F4496219F31CDCBa6130B5402873624585615a | Wormhole Sender |
WORMHOLE_SENDER.sendMessage(targets, values, datas, UNISWAP_WORMHOLE_MESSAGE_RECEIVER, CELO_CHAIN_ID)
encodes:
V2_FACTORY.setFeeTo(TOKEN_JAR)
V2_FACTORY.setFeeToSetter(CROSS_CHAIN_ACCOUNT)
V3_FACTORY.setOwner(V3_OPEN_FEE_ADAPTER)
V4_POOL_MANAGER.transferOwnership(CROSS_CHAIN_ACCOUNT)
This action sets the fee collector of UniswapV2Factory to TokenJar and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter.
RELEVANT ADDRESSES:
| Name | Network | Address | Description |
|---|---|---|---|
| V2_FACTORY | BNB Chain | 0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6 | Uniswap V2 Factory |
| V3_FACTORY | BNB Chain | 0xdB1d10011AD0Ff90774D0C6Bb92e5C5c8b4461F7 | Uniswap V3 Factory |
| UNISWAP_WORMHOLE_MESSAGE_RECEIVER | BNB Chain | 0x341c1511141022cf8eE20824Ae0fFA3491F1302b | Governance Owned Wormhole Receiver |
| TOKEN_JAR | BNB Chain | 0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A | Fee Collector |
| V3_OPEN_FEE_ADAPTER | BNB Chain | 0x3F07F08b45912dCd6691C5B9412975D5113B2910 | Uniswap V3 Fee Adapter |
| WORMHOLE_SENDER | Ethereum | 0xf5F4496219F31CDCBa6130B5402873624585615a | Wormhole Sender |
WORMHOLE_SENDER.sendMessage(targets, values, datas, UNISWAP_WORMHOLE_MESSAGE_RECEIVER, BNB_CHAIN_ID)
encodes:
V2_FACTORY.setFeeTo(TOKEN_JAR)
V3_FACTORY.setOwner(V3_OPEN_FEE_ADAPTER)
This action sets the fee collector of UniswapV2Factory to TokenJar and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter.
RELEVANT ADDRESSES:
| Name | Network | Address | Description |
|---|---|---|---|
| V2_FACTORY | Polygon | 0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C | Uniswap V2 Factory |
| V3_FACTORY | Polygon | 0x1F98431c8aD98523631AE4a59f267346ea31F984 | Uniswap V3 Factory |
| ETHEREUM_PROXY | Polygon | 0x8a1B966aC46F42275860f905dbC75EfBfDC12374 | Governance Owned FxChild Receiver |
| TOKEN_JAR | Polygon | 0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A | Fee Collector |
| V3_OPEN_FEE_ADAPTER | Polygon | 0x3F07F08b45912dCd6691C5B9412975D5113B2910 | Uniswap V3 Fee Adapter |
| POLYGON_FX_ROOT | Ethereum | 0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2 | Polygon's Sender (on Ethereum) |
POLYGON_FX_ROOT.sendMessageToChild(ETHEREUM_PROXY, abi.encode(targets, datas, values))
encodes:
V2_FACTORY.setFeeTo(TOKEN_JAR)
V3_FACTORY.setOwner(V3_OPEN_FEE_ADAPTER)
This seems like a coherent next step for Uniswap's fee rollout strategy. Extending fee collection and UNI burn infrastructure gradually across additional chains makes sense given Uniswap's increasingly multi-chain reality.
I also appreciate the incremental approach rather than a one-shot activation everywhere at once. The main aspect worth monitoring over time is probably the growing cross-chain governance and messaging complexity (Wormhole, adapters, bridge infrastructure, etc.), especially as more chains are added.
This seems like a coherent next step for Uniswap's fee rollout strategy. Extending fee collection and UNI burn infrastructure gradually across additional chains makes sense given Uniswap's increasingly multi-chain reality.
I also appreciate the incremental approach rather than a one-shot activation everywhere at once. The main aspect worth monitoring over time is probably the growing cross-chain governance and messaging complexity (Wormhole, adapters, bridge infrastructure, etc.), especially as more chains are added.
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We voted FOR
Before voting, we asked our Research Team to independently verify the implementation, deployed contracts, and expected governance payloads associated with this proposal.
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We voted FOR
Before voting, we asked our Research Team to independently verify the implementation, deployed contracts, and expected governance payloads associated with this proposal.
Our Research Team reviewed prop-4 in the Uniswap protocol-fees repository PR #130 and pinned the review to commit 83df8d7f. They rebuilt the commit and compared the deployed runtime bytecode on Celo, BNB, and Polygon against the build artifacts. All 10 relevant contracts matched after accounting for compiler metadata and immutable slots, and the immutable values read on-chain matched the expected values from Constants.sol.
The team also reconstructed the three proposal action payloads and produced the expected keccak256(datas[i]) hashes that should match once the on-chain proposal is submitted:
Based on the continuity with the previously approved framework, the unchanged fee structure, and the independent verification performed by our Research Team, we are comfortable supporting this proposal.
We also believe the protocol would benefit from a more comprehensive post-UNIfication report covering operational and economic metrics across deployed chains. As the fee framework continues to expand, providing delegates with clearer visibility into protocol revenue, burn activity, liquidity impact, and cross-chain operational performance would improve governance oversight and help inform future expansion proposals.
Voted FOR this proposal to continue the protocol fee rollout by expanding fee collection and UNI burn infrastructure to Polygon and BNB Chain, while completing Celo's activation through the corrected cross-chain governance path.
This is a logical continuation of UNIfication and the prior protocol fee expansion votes. The burn mechanism is live and working: fees accumulate in TokenJars across chains, searchers call release(), UNI is burned, and TokenJar assets are distributed. Since the first release on Dec. 29, 2025, the system has already produced meaningful burn activity across Ethereum, Base, Arbitrum, Unichain, and OP Mainnet.
Voted FOR this proposal to continue the protocol fee rollout by expanding fee collection and UNI burn infrastructure to Polygon and BNB Chain, while completing Celo's activation through the corrected cross-chain governance path.
This is a logical continuation of UNIfication and the prior protocol fee expansion votes. The burn mechanism is live and working: fees accumulate in TokenJars across chains, searchers call release(), UNI is burned, and TokenJar assets are distributed. Since the first release on Dec. 29, 2025, the system has already produced meaningful burn activity across Ethereum, Base, Arbitrum, Unichain, and OP Mainnet.
For this vote, I also created an updated graphic to make the mechanism easier to understand. The first graphic explains the original protocol fee collection flow and first UNI burn. The new graphic summarizes verified burn counts from Dec. 29, 2025 through May 20, 2026, showing how the Firepit/Releaser system has continued operating across active chains.
Expanding to Polygon and BNB Chain makes sense given Uniswap's multi-chain footprint, while Celo should be completed because governance already approved its inclusion and the prior execution issue was a configuration problem rather than a policy rejection.
As more chains are added, delegates should continue monitoring cross-chain messaging complexity, burn activity, and protocol revenue by chain. But based on the continuity with the existing fee framework, unchanged fee levels, and the fact that the burn system is already operating as designed, Axia supports this proposal.
See more here: https://rikagoldberg.xyz/work-samples
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We voted FOR
Before voting, we asked our Research Team to independently verify the implementation, deployed contracts, and expected governance payloads associated with this proposal.
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We voted FOR
Before voting, we asked our Research Team to independently verify the implementation, deployed contracts, and expected governance payloads associated with this proposal.
Our Research Team reviewed prop-4 in the Uniswap protocol-fees repository PR #130 and pinned the review to commit 83df8d7f. They rebuilt the commit and compared the deployed runtime bytecode on Celo, BNB, and Polygon against the build artifacts. All 10 relevant contracts matched after accounting for compiler metadata and immutable slots, and the immutable values read on-chain matched the expected values from Constants.sol.
The team also reconstructed the three proposal action payloads and produced the expected keccak256(datas[i]) hashes that should match once the on-chain proposal is submitted:
Based on the continuity with the previously approved framework, the unchanged fee structure, and the independent verification performed by our Research Team, we are comfortable supporting this proposal.
We also believe the protocol would benefit from a more comprehensive post-UNIfication report covering operational and economic metrics across deployed chains. As the fee framework continues to expand, providing delegates with clearer visibility into protocol revenue, burn activity, liquidity impact, and cross-chain operational performance would improve governance oversight and help inform future expansion proposals.
Voted FOR this proposal to continue the protocol fee rollout by expanding fee collection and UNI burn infrastructure to Polygon and BNB Chain, while completing Celo's activation through the corrected cross-chain governance path.
This is a logical continuation of UNIfication and the prior protocol fee expansion votes. The burn mechanism is live and working: fees accumulate in TokenJars across chains, searchers call release(), UNI is burned, and TokenJar assets are distributed. Since the first release on Dec. 29, 2025, the system has already produced meaningful burn activity across Ethereum, Base, Arbitrum, Unichain, and OP Mainnet.
Voted FOR this proposal to continue the protocol fee rollout by expanding fee collection and UNI burn infrastructure to Polygon and BNB Chain, while completing Celo's activation through the corrected cross-chain governance path.
This is a logical continuation of UNIfication and the prior protocol fee expansion votes. The burn mechanism is live and working: fees accumulate in TokenJars across chains, searchers call release(), UNI is burned, and TokenJar assets are distributed. Since the first release on Dec. 29, 2025, the system has already produced meaningful burn activity across Ethereum, Base, Arbitrum, Unichain, and OP Mainnet.
For this vote, I also created an updated graphic to make the mechanism easier to understand. The first graphic explains the original protocol fee collection flow and first UNI burn. The new graphic summarizes verified burn counts from Dec. 29, 2025 through May 20, 2026, showing how the Firepit/Releaser system has continued operating across active chains.
Expanding to Polygon and BNB Chain makes sense given Uniswap's multi-chain footprint, while Celo should be completed because governance already approved its inclusion and the prior execution issue was a configuration problem rather than a policy rejection.
As more chains are added, delegates should continue monitoring cross-chain messaging complexity, burn activity, and protocol revenue by chain. But based on the continuity with the existing fee framework, unchanged fee levels, and the fact that the burn system is already operating as designed, Axia supports this proposal.
See more here: https://rikagoldberg.xyz/work-samples