# \[Temp Check\] - Update Crosschain Governance Parameters for Avalanche, MegaETH, Soneium, and X Layer **URL:** \ **Category:** Requests for Comment\ **Created:** [June 19, 2026, 5:04pm UTC](https://gov.uniswap.org/t/temp-check-update-crosschain-governance-parameters-for-avalanche-megaeth-soneium-and-x-layer/26127 "2026-06-19T17:04:30Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![eek637](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/eek637/32/7037_2.png) [@eek637](https://gov.uniswap.org/u/eek637)\ **Post date:** [June 19, 2026, 5:04pm UTC](https://gov.uniswap.org/t/temp-check-update-crosschain-governance-parameters-for-avalanche-megaeth-soneium-and-x-layer/26127/1 "2026-06-19T17:04:30Z")
## 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) ---
**Author:** ![SilentSwap\_BD](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/silentswap_bd/32/10594_2.png) [@SilentSwap\_BD](https://gov.uniswap.org/u/SilentSwap_BD)\ **Post date:** [June 29, 2026, 2:39pm UTC](https://gov.uniswap.org/t/temp-check-update-crosschain-governance-parameters-for-avalanche-megaeth-soneium-and-x-layer/26127/2 "2026-06-29T14:39:31Z")
Excellent and timely proposal, @eek637. Standardizing on CrossChainAccount contracts and migrating to the updated Wormhole infrastructure is a logical step for robust cross chain governance, especially with high performance ecosystems like Soneium and MegaETH scaling rapidly. As the Foundation continually refines these cross chain architecture and parameter best practices, has the committee explored how cross-chain privacy preserving components might interface with these executors? As enterprise backed chains grow, introducing native, compliant execution layer privacy or ZK-proof hooks alongside these standardized governance structures could drastically accelerate institutional confidence in managing multi-chain liquidity. Would love to hear the team’s perspective on how privacy fits into the broader multi-chain deployment framework moving forward. ---
**Author:** ![Abel189](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@Abel189](https://gov.uniswap.org/u/Abel189)\ **Post date:** [June 30, 2026, 6:13pm UTC](https://gov.uniswap.org/t/temp-check-update-crosschain-governance-parameters-for-avalanche-megaeth-soneium-and-x-layer/26127/3 "2026-06-30T18:13:35Z")
I support this proposal. One aspect I particularly appreciate is that it improves the governance infrastructure without changing the governance process itself. Upgrading the messaging layer, replacing deprecated components, and adopting a more standardized ownership model all contribute to making crosschain governance more robust while preserving the existing governance framework. I also view the migration toward CrossChainAccount contracts as a positive step. Replacing aliased addresses with dedicated contracts improves clarity, reduces operational complexity, and lowers the risk of errors during future governance actions. As Uniswap continues to expand across multiple chains, having consistent governance infrastructure becomes increasingly valuable. Finally, infrastructure upgrades such as this are often less visible than feature proposals, yet they are fundamental for long-term protocol resilience. Continuing to modernize governance execution while maintaining transparency and minimizing operational risk is, in my view, an important investment in the protocol’s future. ---
**Author:** ![Manugotsuka](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/manugotsuka/32/10202_2.png) [@Manugotsuka](https://gov.uniswap.org/u/Manugotsuka)\ **Post date:** [July 2, 2026, 2:52pm UTC](https://gov.uniswap.org/t/temp-check-update-crosschain-governance-parameters-for-avalanche-megaeth-soneium-and-x-layer/26127/4 "2026-07-02T14:52:47Z")
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and is based on their combined research, fact-checking, and discussion. **We voted FOR.** Crosschain governance is an important part of how Uniswap operates across multiple networks, and it makes sense to keep that infrastructure up to date as deployments evolve and older messaging systems become less suitable. Moving Avalanche and MegaETH away from LayerZero v1 is a reasonable step. Given the direction of LayerZero v1 and the bridge work already done by the Uniswap Foundation, we think migrating these deployments to a more actively supported messaging path is the right direction. We also support moving Soneium and X Layer away from aliased timelock ownership and toward CrossChainAccount contracts. Aliased ownership on OP Stack chains can be unintuitive and easier to mishandle, while CrossChainAccount provides a clearer and more explicit ownership structure for executing governance actions from Ethereum. Before voting, we asked our Research Team to review the proposal. Their view was that the overall direction is sound: moving away from LayerZero v1 makes sense, and the proposed CrossChainAccount changes are a cleaner setup for Soneium and X Layer. The main nuance they raised is around MegaETH. If a canonical bridge path is available there, it would be helpful to understand why the proposal uses Wormhole instead of the canonical bridge, especially when CrossChainAccount is already being used for other OP Stack deployments. This does not change our support for the proposal, but we think the design choice is worth clarifying. ---
**Author:** ![eek637](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/eek637/32/7037_2.png) [@eek637](https://gov.uniswap.org/u/eek637)\ **Post date:** [July 2, 2026, 7:15pm UTC](https://gov.uniswap.org/t/temp-check-update-crosschain-governance-parameters-for-avalanche-megaeth-soneium-and-x-layer/26127/5 "2026-07-02T19:15:36Z")
Thanks as always for the thorough review @Manugotsuka, and agree with you on the canonical bridge for MegaETH. We plan to propose a transition over to the CrossChainAccount when we turn fees on there in the coming months. ---
**Author:** ![Manugotsuka](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/manugotsuka/32/10202_2.png) [@Manugotsuka](https://gov.uniswap.org/u/Manugotsuka)\ **Post date:** [July 9, 2026, 1:55pm UTC](https://gov.uniswap.org/t/temp-check-update-crosschain-governance-parameters-for-avalanche-megaeth-soneium-and-x-layer/26127/6 "2026-07-09T13:55:19Z")
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and is based on their combined research, fact-checking, and discussion. We voted FOR. We [supported](https://gov.uniswap.org/t/temp-check-update-crosschain-governance-parameters-for-avalanche-megaeth-soneium-and-x-layer/26127/4) this proposal during the off-chain stage, and we continue to support it at the on-chain stage. In our view, the proposal remains a sensible update to Uniswap’s crosschain governance infrastructure. Moving Avalanche and MegaETH away from LayerZero v1, and moving Soneium and X Layer toward CrossChainAccount contracts, makes the overall setup cleaner and easier to reason about. Before the on-chain vote, we asked our Research Team to review the final proposal. They did not identify any issues that would change our position or give us a reason to vote against.