[Temp Check] - Update Crosschain Governance Parameters for Avalanche, MegaETH, Soneium, and X Layer

Requests for Comment
1

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) 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
OmnichainGovernanceExecutor Avalanche 0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc
OmnichainGovernanceExecutor MegaETH 0x8819b86ddF592c3aaAa6f9ec7cE1A0f99FC4322c
OmnichainGovernanceExecutor MegaETH 0x51F9629C1e75aF07421E662DBEb2B7dc8deDefd9

Proposed Configuration - Avalanche and MegaETH

The LayerZero contracts are replaced with the Wormhole bridge infrastructure from 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
UniswapWormholeReceiver Avalanche 0x47eB0Cf11a1626462Da3C830bCDe64c3F582B5a6
UniswapWormholeReceiver MegaETH 0xa107580F73BD797Bd8b87Ff24e98346D99F93DdB

For a detailed discussion of how Wormhole works, please see this report 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
Alias Address Soneium 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
CrossChainAccount Soneium 0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7

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

2 Likes
2

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.

3

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.

4

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.

5

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.

1 Like
6

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 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.