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 to confirm their validity.
Mainnet
| Contract | Address |
|---|---|
| V3OpenFeeAdapter | 0x3e40DB80450f025b01E45c58b0aF763C7A29a8bd |
| V3FeeAdapter | 0x5E74C9f42EEd283bFf3744fBD1889d398d40867d |
Arbitrum
| Contract | Address |
|---|---|
| TokenJar | 0x95E337C5B155385945D407f5396387D0c2a3A263 |
| Releaser (ArbitrumBridgedResourceFirepit) | 0xB8018422bcE25D82E70cB98FdA96a4f502D89427 |
| V3OpenFeeAdapter | 0xFF7aD5dA31fECdC678796c88B05926dB896b0699 |
| UniswapV3Factory | 0x1F98431c8aD98523631AE4a59f267346ea31F984 |
| UniswapV2Factory | 0xf1D7CC64Fb4452F05c498126312eBE29f30Fbcf9 |
OP Mainnet
| Contract | Address |
|---|---|
| TokenJar | 0xb13285DF724ea75f3f1E9912010B7e491dCd5EE3 |
| Releaser (OptimismBridgedResourceFirepit) | 0x94460443Ca27FFC1baeCa61165fde18346C91AbD |
| V3OpenFeeAdapter | 0xec23Cf5A1db3dcC6595385D28B2a4D9B52503Be4 |
| UniswapV3Factory | 0x1F98431c8aD98523631AE4a59f267346ea31F984 |
| UniswapV2Factory | 0x0c3c1c532F1e39EdF36BE9Fe0bE1410313E074Bf |
Base
| Contract | Address |
|---|---|
| TokenJar | 0x9bD25e67bF390437C8fAF480AC735a27BcF6168c |
| Releaser (OptimismBridgedResourceFirepit) | 0xFf77c0ED0B6b13A20446969107E5867abc46f53a |
| V3OpenFeeAdapter | 0xaBEA76658b205696d49B5F91b2a03536cB8A3bE1 |
| UniswapV3Factory | 0x33128a8fC17869897dcE68Ed026d694621f6FDfD |
| UniswapV2Factory | 0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6 |
Celo
| Contract | Address |
|---|---|
| CrossChainAccount | 0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7 |
| UniswapV3Factory | 0xAfE208a311B21f13EF87E33A90049fC17A7acDEc |
| UniswapV2Factory | 0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7 |
This is the first proposal to use the new governance process approved 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.
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 on Ethereum mainnet since December. The burn system is working as expected, permissionlessly converting fees in many different tokens into UNI burns.
Now, we propose to:
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 for OP Stack chains, and ArbitrumBridgedResourceFirepit 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.
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.
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 to confirm their validity.
Mainnet
| Contract | Address |
|---|---|
| V3OpenFeeAdapter | 0x3e40DB80450f025b01E45c58b0aF763C7A29a8bd |
| V3FeeAdapter | 0x5E74C9f42EEd283bFf3744fBD1889d398d40867d |
Arbitrum
| Contract | Address |
|---|---|
| TokenJar | 0x95E337C5B155385945D407f5396387D0c2a3A263 |
| Releaser (ArbitrumBridgedResourceFirepit) | 0xB8018422bcE25D82E70cB98FdA96a4f502D89427 |
| V3OpenFeeAdapter | 0xFF7aD5dA31fECdC678796c88B05926dB896b0699 |
| UniswapV3Factory | 0x1F98431c8aD98523631AE4a59f267346ea31F984 |
| UniswapV2Factory | 0xf1D7CC64Fb4452F05c498126312eBE29f30Fbcf9 |
OP Mainnet
| Contract | Address |
|---|---|
| TokenJar | 0xb13285DF724ea75f3f1E9912010B7e491dCd5EE3 |
| Releaser (OptimismBridgedResourceFirepit) | 0x94460443Ca27FFC1baeCa61165fde18346C91AbD |
| V3OpenFeeAdapter | 0xec23Cf5A1db3dcC6595385D28B2a4D9B52503Be4 |
| UniswapV3Factory | 0x1F98431c8aD98523631AE4a59f267346ea31F984 |
| UniswapV2Factory | 0x0c3c1c532F1e39EdF36BE9Fe0bE1410313E074Bf |
Base
| Contract | Address |
|---|---|
| TokenJar | 0x9bD25e67bF390437C8fAF480AC735a27BcF6168c |
| Releaser (OptimismBridgedResourceFirepit) | 0xFf77c0ED0B6b13A20446969107E5867abc46f53a |
| V3OpenFeeAdapter | 0xaBEA76658b205696d49B5F91b2a03536cB8A3bE1 |
| UniswapV3Factory | 0x33128a8fC17869897dcE68Ed026d694621f6FDfD |
| UniswapV2Factory | 0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6 |
Celo
| Contract | Address |
|---|---|
| CrossChainAccount | 0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7 |
| UniswapV3Factory | 0xAfE208a311B21f13EF87E33A90049fC17A7acDEc |
| UniswapV2Factory | 0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7 |
This is the first proposal to use the new governance process approved 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.
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 on Ethereum mainnet since December. The burn system is working as expected, permissionlessly converting fees in many different tokens into UNI burns.
Now, we propose to:
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 for OP Stack chains, and ArbitrumBridgedResourceFirepit 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.
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.
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 the fee expansion in Votes 1 and 2.
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 the fee expansion in Votes 1 and 2.
Following our previous support at the Temperature Check stage, we are extending that position to the on-chain stage as well. These votes implement the UNIfication framework without changing fee parameters and represent execution of previously approved direction.
Ahead of the Temperature Check, we requested a full technical review from the L2BEAT Research Team. That analysis, which informed our initial position, is available here, and our vote today remains consistent with those findings.
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 the fee expansion in Votes 1 and 2.
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 the fee expansion in Votes 1 and 2.
Following our previous support at the Temperature Check stage, we are extending that position to the on-chain stage as well. These votes implement the UNIfication framework without changing fee parameters and represent execution of previously approved direction.
Ahead of the Temperature Check, we requested a full technical review from the L2BEAT Research Team. That analysis, which informed our initial position, is available here, and our vote today remains consistent with those findings.
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.
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.
We view it as a natural continuation of the UNIfication framework approved in December, extending the existing fee collection and UNI burn architecture to additional chains and replacing the curated v3 allowlist with a universal adapter. Fee parameters remain unchanged. Before voting, we asked our research team to validate the full implementation, including contract behavior and burn mechanics.
For a detailed technical breakdown of what was verified, what remains unpublished, and the associated risks, please see the full analysis below. This review was conducted by the L2BEAT Research Team as part of the independent technical due diligence we require before voting on proposals of this scope.
Proposal #93 "UNIfication" passed in December 2025. It burned 100M UNI, turned on protocol fees for V2 and V3 on Ethereum mainnet, and approved a 40M UNI growth budget for Uniswap Labs over two years. In return, Labs eliminated all interface, wallet, and API fees.
UNIfication deployed three new contracts:
releaser can withdraw.0xdead .The Temp Check - authored by Hayden Adams - does two things:
1. Expand protocol fees to eight L2s: Arbitrum, Base, Celo, OP Mainnet, Soneium, Worldchain, X Layer, and Zora. Both V2 and V3 pools are on each chain.
2. Replace the curated Merkle adapter with an open one. The new V3OpenFeeAdapter drops the allowlist entirely. Every V3 pool inherits a protocol fee by default. Governance can exempt individual pools, but the default is fees on.
Due to GovernorBravo's 10-action limit, execution splits into two parallel proposals:
The fee collection and burn architecture extends the mainnet system to L2s with chain-specific bridging:
Pools (v2/v3) on each chain
│
â–Ľ
TokenJar ─── Immutable fee sink. Holds all collected tokens.
│
â–Ľ
Releaser ─── Searcher pays UNI threshold, receives fee tokens.
│
├─ Ethereum: Firepit ─── UNI sent to 0xdead directly
├─ OP Stack: OptimismBridgedResourceFirepit ─── bridges UNI to L1 0xdead
└─ Arbitrum: ArbitrumBridgedResourceFirepit ─── bridges UNI to L1 0xdead
The protocol never converts fee tokens into UNI. Instead, it relies on a searcher auction: fee tokens accumulate in the TokenJar until a searcher decides the pot is worth more than the fixed UNI cost. The searcher pays 4,000 UNI (mainnet) or 2,000 UNI (L2s), receives all accumulated tokens, and the UNI is burned. The design avoids DEX routing, slippage management, and oracle dependency - burn frequency depends entirely on searcher competition and accumulated value.
On L2s, UNI doesn't burn locally. It bridges to Ethereum L1 first, via L2StandardBridge on OP Stack chains, via L2GatewayRouter on Arbitrum - and once the withdrawal finalises, it is burnt by transfer to the 0xdead address.
The old adapter required a Merkle proof to set fees on a pool - governance curated the list, targeting pools where Uniswap held 90%+ market share to minimize LP attrition risk. The new adapter inverts the default:
| Merkle-based (current) | Open adapter (proposed) | |
|---|---|---|
| New pools | No fee unless added to Merkle tree | Fee on - inherits tier default |
| Opt-out | Not in the tree = no fee | Only via governance poolOverride to zero |
| Coverage | ~80-95% of volume | 100% of V3 pools |
The adapter resolves fees through a three-level waterfall: pool-specific override, then fee-tier default, then global default. A ZERO_FEE_SENTINEL (value 255) distinguishes "not configured" from "explicitly exempt." Anyone can call triggerFeeUpdate() to apply the current fee to any pool - no governance action required.
Fee parameters are identical to December's UNIfication. No increase:
| LP Fee Tier | Protocol Take | Effective Protocol Fee |
|---|---|---|
| 0.01% | 1/4 of LP fees | ~0.0025% |
| 0.05% | 1/4 of LP fees | ~0.0125% |
| 0.30% | 1/6 of LP fees | ~0.05% |
| 1.00% | 1/6 of LP fees | ~0.167% |
Risks
The shift from allowlist to universal bets that Uniswap's network effects hold across the full pool spectrum - not just popular pairs. The risk is economic and reversible (governance can exempt pools), not a security concern.
We reviewed the source code on the protocol-fees repository (main branch, no pinned commit hash provided)
onlyReleaser withdrawal - confirmed.RESOURCE_RECIPIENT = address(0xdead) - confirmed.L2StandardBridge.withdrawTo() to L1 0xdead - confirmed. Covers Base, OP Mainnet, Soneium, Worldchain, Zora.L2GatewayRouter.outboundTransfer() - confirmed.0x44, 0x66) match original UNIfication deployer - confirmed.0x2BAD...46CD) - confirmed for OP Stack and Arbitrum.Contracts are immutable (no proxy pattern), but governance retains control: it can swap the releaser on any TokenJar (redirecting fee flow), adjust release thresholds, set per-pool fee overrides, and transfer V3 Factory ownership to a future adapter.
Several elements remain unpublished ahead of the on-chain vote:
Celo and X Layer have no public implementation. No custom releasers, no deployment scripts, and no bridge contracts were found in the public repo. We cannot assess how UNI gets burned on these chains.
No on-chain proposal scripts are published. The Snapshot body contains pseudocode for Proposals A and B, but the actual FeeExpansionProposal scripts couldn’t be found in the repo. Exact calldata cannot be independently verified.
Audit scope is unclear. OpenZeppelin and Spearbit audited the original UNIfication contracts. Whether the new V3OpenFeeAdapter and L2-specific deployments fall within that audit scope - or require a separate review - has not been confirmed (?).
Bridged UNI addresses for three chains are TBD. Soneium, Worldchain, and Zora don't yet have confirmed UNI token addresses in the deployment parameters.
Proposal A extends existing rates to new chains without increasing them. The universal fee adapter is a policy shift - from opt-in to opt-out - it's an economic risk, not a security one.
Proposal B (Celo, Soneium, Worldchain, X Layer, Zora) covers chains whose bridge and burn path cannot be verified from public sources. Until the Celo and X Layer releaser contracts are published, delegates cannot confirm how - or whether - UNI gets burned on those chains.
My recommendation: The direction is sound for both proposals: extending proven fee infrastructure to new chains at unchanged rates.
Before the on-chain vote, delegates should require the proposer to publish:
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.
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.
We view it as a natural continuation of the UNIfication framework approved in December, extending the existing fee collection and UNI burn architecture to additional chains and replacing the curated v3 allowlist with a universal adapter. Fee parameters remain unchanged. Before voting, we asked our research team to validate the full implementation, including contract behavior and burn mechanics.
For a detailed technical breakdown of what was verified, what remains unpublished, and the associated risks, please see the full analysis below. This review was conducted by the L2BEAT Research Team as part of the independent technical due diligence we require before voting on proposals of this scope.
Proposal #93 "UNIfication" passed in December 2025. It burned 100M UNI, turned on protocol fees for V2 and V3 on Ethereum mainnet, and approved a 40M UNI growth budget for Uniswap Labs over two years. In return, Labs eliminated all interface, wallet, and API fees.
UNIfication deployed three new contracts:
releaser can withdraw.0xdead .The Temp Check - authored by Hayden Adams - does two things:
1. Expand protocol fees to eight L2s: Arbitrum, Base, Celo, OP Mainnet, Soneium, Worldchain, X Layer, and Zora. Both V2 and V3 pools are on each chain.
2. Replace the curated Merkle adapter with an open one. The new V3OpenFeeAdapter drops the allowlist entirely. Every V3 pool inherits a protocol fee by default. Governance can exempt individual pools, but the default is fees on.
Due to GovernorBravo's 10-action limit, execution splits into two parallel proposals:
The fee collection and burn architecture extends the mainnet system to L2s with chain-specific bridging:
Pools (v2/v3) on each chain
│
â–Ľ
TokenJar ─── Immutable fee sink. Holds all collected tokens.
│
â–Ľ
Releaser ─── Searcher pays UNI threshold, receives fee tokens.
│
├─ Ethereum: Firepit ─── UNI sent to 0xdead directly
├─ OP Stack: OptimismBridgedResourceFirepit ─── bridges UNI to L1 0xdead
└─ Arbitrum: ArbitrumBridgedResourceFirepit ─── bridges UNI to L1 0xdead
The protocol never converts fee tokens into UNI. Instead, it relies on a searcher auction: fee tokens accumulate in the TokenJar until a searcher decides the pot is worth more than the fixed UNI cost. The searcher pays 4,000 UNI (mainnet) or 2,000 UNI (L2s), receives all accumulated tokens, and the UNI is burned. The design avoids DEX routing, slippage management, and oracle dependency - burn frequency depends entirely on searcher competition and accumulated value.
On L2s, UNI doesn't burn locally. It bridges to Ethereum L1 first, via L2StandardBridge on OP Stack chains, via L2GatewayRouter on Arbitrum - and once the withdrawal finalises, it is burnt by transfer to the 0xdead address.
The old adapter required a Merkle proof to set fees on a pool - governance curated the list, targeting pools where Uniswap held 90%+ market share to minimize LP attrition risk. The new adapter inverts the default:
| Merkle-based (current) | Open adapter (proposed) | |
|---|---|---|
| New pools | No fee unless added to Merkle tree | Fee on - inherits tier default |
| Opt-out | Not in the tree = no fee | Only via governance poolOverride to zero |
| Coverage | ~80-95% of volume | 100% of V3 pools |
The adapter resolves fees through a three-level waterfall: pool-specific override, then fee-tier default, then global default. A ZERO_FEE_SENTINEL (value 255) distinguishes "not configured" from "explicitly exempt." Anyone can call triggerFeeUpdate() to apply the current fee to any pool - no governance action required.
Fee parameters are identical to December's UNIfication. No increase:
| LP Fee Tier | Protocol Take | Effective Protocol Fee |
|---|---|---|
| 0.01% | 1/4 of LP fees | ~0.0025% |
| 0.05% | 1/4 of LP fees | ~0.0125% |
| 0.30% | 1/6 of LP fees | ~0.05% |
| 1.00% | 1/6 of LP fees | ~0.167% |
Risks
The shift from allowlist to universal bets that Uniswap's network effects hold across the full pool spectrum - not just popular pairs. The risk is economic and reversible (governance can exempt pools), not a security concern.
We reviewed the source code on the protocol-fees repository (main branch, no pinned commit hash provided)
onlyReleaser withdrawal - confirmed.RESOURCE_RECIPIENT = address(0xdead) - confirmed.L2StandardBridge.withdrawTo() to L1 0xdead - confirmed. Covers Base, OP Mainnet, Soneium, Worldchain, Zora.L2GatewayRouter.outboundTransfer() - confirmed.0x44, 0x66) match original UNIfication deployer - confirmed.0x2BAD...46CD) - confirmed for OP Stack and Arbitrum.Contracts are immutable (no proxy pattern), but governance retains control: it can swap the releaser on any TokenJar (redirecting fee flow), adjust release thresholds, set per-pool fee overrides, and transfer V3 Factory ownership to a future adapter.
Several elements remain unpublished ahead of the on-chain vote:
Celo and X Layer have no public implementation. No custom releasers, no deployment scripts, and no bridge contracts were found in the public repo. We cannot assess how UNI gets burned on these chains.
No on-chain proposal scripts are published. The Snapshot body contains pseudocode for Proposals A and B, but the actual FeeExpansionProposal scripts couldn’t be found in the repo. Exact calldata cannot be independently verified.
Audit scope is unclear. OpenZeppelin and Spearbit audited the original UNIfication contracts. Whether the new V3OpenFeeAdapter and L2-specific deployments fall within that audit scope - or require a separate review - has not been confirmed (?).
Bridged UNI addresses for three chains are TBD. Soneium, Worldchain, and Zora don't yet have confirmed UNI token addresses in the deployment parameters.
Proposal A extends existing rates to new chains without increasing them. The universal fee adapter is a policy shift - from opt-in to opt-out - it's an economic risk, not a security one.
Proposal B (Celo, Soneium, Worldchain, X Layer, Zora) covers chains whose bridge and burn path cannot be verified from public sources. Until the Celo and X Layer releaser contracts are published, delegates cannot confirm how - or whether - UNI gets burned on those chains.
My recommendation: The direction is sound for both proposals: extending proven fee infrastructure to new chains at unchanged rates.
Before the on-chain vote, delegates should require the proposer to publish:
yeah typo in the text. in prepping for the proposal, the first contract deployment went out without the default fee configured. that deployment was added to docs and description. the default fee being set to 0 was discovered on review and a new contract was deployed. the testing scripts were update with the new address, the description was not.
Assuming your second question is about Celo:
yeah typo in the text. in prepping for the proposal, the first contract deployment went out without the default fee configured. that deployment was added to docs and description. the default fee being set to 0 was discovered on review and a new contract was deployed. the testing scripts were update with the new address, the description was not.
Assuming your second question is about Celo:
LMK if you have any more questions.
Thanks for clarification.
Am I correct in assuming this is a typo in the text? Was this an accident or was the address changed for some reason?
And there is a second question already connected with the second vote - why is the part on the execution of Sela included in both the first and the second part?
The correct address is 0xf2371551Fe3937Db7c750f4DfABe5c2fFFdcBf5A. The only difference between the contracts is a global default fee setting. There's a getter function for that parameter (defaultFee()) so you can confirm on Etherscan. More info on fee resolution can be found here. Thanks for your diligence!
While reviewing the calldata for Function 4 in the onchain proposal, I noticed that the address being passed to:
V3FeeAdapter.setFactoryOwner(address)
is:
0xf2371551Fe3937Db7c750f4DfABe5c2fFFdcBf5A
However, in the proposal description and documentation, the mainnet V3OpenFeeAdapter is listed as:
0x3e40DB80450f025b01E45c58b0aF763C7A29a8bd
While reviewing the calldata for Function 4 in the onchain proposal, I noticed that the address being passed to:
V3FeeAdapter.setFactoryOwner(address)
is:
0xf2371551Fe3937Db7c750f4DfABe5c2fFFdcBf5A
However, in the proposal description and documentation, the mainnet V3OpenFeeAdapter is listed as:
0x3e40DB80450f025b01E45c58b0aF763C7A29a8bd
Could the team clarify why a different address is being used in the execution payload compared to the one referenced in the proposal specification?
Thanks in advance for the clarification.
yeah typo in the text. in prepping for the proposal, the first contract deployment went out without the default fee configured. that deployment was added to docs and description. the default fee being set to 0 was discovered on review and a new contract was deployed. the testing scripts were update with the new address, the description was not.
Assuming your second question is about Celo:
yeah typo in the text. in prepping for the proposal, the first contract deployment went out without the default fee configured. that deployment was added to docs and description. the default fee being set to 0 was discovered on review and a new contract was deployed. the testing scripts were update with the new address, the description was not.
Assuming your second question is about Celo:
LMK if you have any more questions.
Thanks for clarification.
Am I correct in assuming this is a typo in the text? Was this an accident or was the address changed for some reason?
And there is a second question already connected with the second vote - why is the part on the execution of Sela included in both the first and the second part?
The correct address is 0xf2371551Fe3937Db7c750f4DfABe5c2fFFdcBf5A. The only difference between the contracts is a global default fee setting. There's a getter function for that parameter (defaultFee()) so you can confirm on Etherscan. More info on fee resolution can be found here. Thanks for your diligence!
While reviewing the calldata for Function 4 in the onchain proposal, I noticed that the address being passed to:
V3FeeAdapter.setFactoryOwner(address)
is:
0xf2371551Fe3937Db7c750f4DfABe5c2fFFdcBf5A
However, in the proposal description and documentation, the mainnet V3OpenFeeAdapter is listed as:
0x3e40DB80450f025b01E45c58b0aF763C7A29a8bd
While reviewing the calldata for Function 4 in the onchain proposal, I noticed that the address being passed to:
V3FeeAdapter.setFactoryOwner(address)
is:
0xf2371551Fe3937Db7c750f4DfABe5c2fFFdcBf5A
However, in the proposal description and documentation, the mainnet V3OpenFeeAdapter is listed as:
0x3e40DB80450f025b01E45c58b0aF763C7A29a8bd
Could the team clarify why a different address is being used in the execution payload compared to the one referenced in the proposal specification?
Thanks in advance for the clarification.
Hey @Manugotsuka nice analysis, thank you! Proposal 95 was just posted with links to the deployed fee infra contracts. There's an outstanding PR on the fee contract repo that notes them as well, I'll get that merged.
Hey @Manugotsuka nice analysis, thank you! Proposal 95 was just posted with links to the deployed fee infra contracts. There's an outstanding PR on the fee contract repo that notes them as well, I'll get that merged.