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