[Temp Check] Protocol Fee Expansion: Arc

Temperature Check
1

This proposal is part of the protocol fee rollout, following proposals #93, #94, #95, #96, #99, and #100. 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 last year, the rollout has extended to eleven additional chains: Arbitrum, Base, OP Mainnet, Worldchain, X Layer, Soneium, Zora, Celo, BNB Chain, Polygon, and Robinhood Chain. 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.

Arc is a Layer 1 built by Circle for the world’s financial markets, real-time money movement, and agentic economic activity, with mainnet going live September 16, 2026. Uniswap was live on Arc from launch, with v2, v3, v4, and UniswapX all deployed.

This proposal:

  • Extends the infrastructure for collecting and burning protocol fees to Arc
  • Enables v2, v3, and v4 protocol fees on Arc

Implementation Details

Governance path. Cross-chain governance messages are sent from the protocol’s Timelock to the UniswapWormholeMessageSender on Ethereum and executed on Arc by UniswapWormholeReceiver. As is the case on Polygon and BNB Chain, the UniswapWormholeMessageReceiver holds the feeToSetter role on the Uniswapv2Factory and the owner role on Uniswapv3Factory and v4’s PoolManager prior to turning on fees.

Burn path. UNI on Arc is a synthetic token under Wormhole’s Native Token Transfer system (NTT). This is a ‘lock, mint, and burn’ system where canonical UNI is locked on Ethereum so a synthetic UNI can be minted on a foreign chain using Wormhole’s NTT infrastructure. More details can be found in the spec here.

Protocol fees generated on Arc burn UNI on mainnet using the Tokenjar and Releaser smart contracts. As on other chains, a searcher pays synthetic UNI on Arc to claim the TokenJar’s accumulated fees. The releaser, WormholeReleaser, sends that synthetic UNI to be burned by the NttManager on Arc, which emits a Wormhole message. The message is forwarded to the NttManager on Ethereum, which sends the corresponding canonical UNI to the burn address. This is the same releaser and the same path already in production on Polygon and BNB Chain.

The AMM and governance message passing contracts have been deployed and are detailed in the table below. The protocol fee infrastructure contracts will be deployed in the coming days and added to the table before the onchain vote goes live.

Implementation details for the v4 fee system are in the v4 fee activation temp check. v2 and v3 protocol fee levels are the same as on all other chains where fees are live. See a breakdown here.

Proposal Spec

If passed, the Arc Fee Activation proposal will execute two sets of calls on Ethereum.

The first registers Arc with the existing mainnet NTT system, setting Arc’s WormholeTransceiver and NttManager as peers of their Ethereum counterparts. On Polygon and BNB Chain this step was permissionless, because the mainnet NTT contracts were being deployed at the same time and had not yet been handed to the Timelock. Those contracts now exist and are governance owned, so registering a new chain against them requires an onchain vote.

WORMHOLE_TRANSCEIVER.setWormholePeer(ARC_WORMHOLE_CHAIN_ID, ARC_WORMHOLE_TRANSCEIVER)
NTT_MANAGER.setPeer(ARC_WORMHOLE_CHAIN_ID, ARC_NTT_MANAGER, 18, 0)

Note that WORMHOLE_CHAIN_ID is a parameter specific to Wormhole, not to be confused with EVM Chain IDs. More details here.

The second call sends the fee activation calls to Arc:

WORMHOLE_SENDER.sendMessage(targets, values, datas, UNISWAP_WORMHOLE_RECEIVER, ARC_WORMHOLE_CHAIN_ID)

encoding:

V2_FACTORY.setFeeTo(TOKEN_JAR)
V3_FACTORY.setOwner(V3_OPEN_FEE_ADAPTER)
V4_POOL_MANAGER.setProtocolFeeController(V4_FEE_ADAPTER)

Once executed on Arc, these set the fee collector of UniswapV2Factory to TokenJar, transfer ownership of UniswapV3Factory to V3OpenFeeAdapter, and set the v4 PoolManager’s protocol fee controller to V4FeeAdapter.

RELEVANT ADDRESSES:

Name Network Address Description
V2_FACTORY Arc 0x89e5DB8B5aA49aA85AC63f691524311AEB649eba Uniswap V2 Factory
V3_FACTORY Arc 0xf0db7b58379503491d857dB50AC9ece64c653918 Uniswap V3 Factory
V4_POOL_MANAGER Arc 0x8366a39CC670B4001A1121B8F6A443A643e40951 Uniswap V4 Pool Manager
UNISWAP_WORMHOLE_RECEIVER Arc 0xbCA30b5429935205037069cF5b8A165F55d05a75 Governance owned Wormhole receiver
TOKEN_JAR Arc 0xfd39ac616e630e9db03EFB2c9a4Fe63eDB949233 Fee Collector
V3_OPEN_FEE_ADAPTER Arc 0xa59FfbB55D91Fc32b44A06F0b9cc6036a4afbcE2 Uniswap V3 Fee Adapter
V4_FEE_ADAPTER Arc 0x2f2bd3F43880b9644211f16d861b0672aaB23782 Uniswap V4 Fee Adapter
V4_FEE_POLICY Arc 0x9671B518dA771c5c73d8115b3800FA7653a72015 Uniswap V4 Fee Policy
RELEASER Arc 0xe1Adf3f130Abf616a7aB04AEeBf8D0470F6B6a16 WormholeReleaser
NTT_MANAGER Arc 0xcaABe9866eb34178922651d6e51e414B29174A31 Wormhole NTT Manager
WORMHOLE_TRANSCEIVER Arc 0x06e8bdE95BE4ce5cB1134BD47aD18a79fFB35822 Wormhole Transceiver
SYNTHETIC_NTT_UNI Arc 0x0ff2262B299D2a7784Cfb29f944FbAB239Ad1df6 Synthetic UNI
WORMHOLE_SENDER Ethereum 0xf5F4496219F31CDCBa6130B5402873624585615a Wormhole Sender
NTT_MANAGER Ethereum 0x6569925Aac77D6B8Bb085F31F9828ff80D5a0c44 Wormhole NTT Manager
WORMHOLE_TRANSCEIVER Ethereum 0x7597C40Fd3df66b750C14ad4D90524e247499011 Wormhole Transceiver

Next Steps / Timeline

  • Snapshot: Sep 18-23, 2026
  • Onchain vote: Following successful Snapshot
2 Likes
2

We recently added Arc support in Gem Wallet, so this is useful for us to follow. Could you share a simple before-and-after swap example showing whether users’ total fees change or whether the existing fee is shared differently? That would help us explain it clearly to users.

1 Like
3

Protocol fees on Arc are implemented the same as on every other chain, so the impact on users is unchanged from those deployments. However you handle e.g. Base will also work for Arc.

1 Like
4

Thanks for clarifying and pointing to Base as a reference. I’ll pass this along to our team for our Arc fee explanations.

1 Like
5

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 backed the previous protocol fee expansions, and the same reasoning applies to Arc. With Uniswap already deployed there, extending the existing fee collection and UNI burn framework to the network seems like a reasonable next step.

Because this proposal involves new contract deployments, cross-chain infrastructure, and changes to protocol fee parameters, we plan to ask our Research Team to review the final executable once the proposal reaches the on-chain stage.

So, for now, we don’t have any blockers that will make us not support this proposal at this stage.

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 the proposal during the offchain stage, mainly because extending the existing protocol fee framework to Arc felt consistent with the rollout Uniswap has already been doing across other chains.

At that stage, our only real caveat was that the final implementation still needed to be checked once the executable was available. We asked our Research Team to review the onchain proposal, and they confirmed that the calldata matches the description and that the implementation looks fine from a security perspective.

Nothing in the final payload changed our view, so we are reaffirming our FOR vote.

7

The Base comparison is helpful. If Arc uses the same protocol-fee implementation, that separates implementation from realized economic performance.

Once fees are active, what metric should governance use to evaluate whether Arc is actually producing the intended protocol economics: configured fee parameters, TokenJar accrual, realized UNI burn, or some combination of those measures?