# \[Temp Check\] Protocol Fee Expansion: Arc **URL:** \ **Category:** Temperature Check\ **Created:** [September 18, 2026, 2:39pm UTC](https://gov.uniswap.org/t/temp-check-protocol-fee-expansion-arc/26287 "2026-09-18T14:39:50Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![UniswapLabs](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/uniswaplabs/32/5196_2.png) [@UniswapLabs](https://gov.uniswap.org/u/UniswapLabs)\ **Post date:** [September 18, 2026, 2:39pm UTC](https://gov.uniswap.org/t/temp-check-protocol-fee-expansion-arc/26287/1 "2026-09-18T14:39:50Z")
_This proposal is part of the protocol fee rollout, following proposals [#93](https://vote.uniswapfoundation.org/proposals/93), [#94](https://vote.uniswapfoundation.org/proposals/94), [#95](https://vote.uniswapfoundation.org/proposals/95), [#96](https://vote.uniswapfoundation.org/proposals/96), [#99](https://vote.uniswapfoundation.org/proposals/99), and [#100](https://vote.uniswapfoundation.org/proposals/100). It uses the expedited governance process [approved](https://gov.uniswap.org/t/unification-proposal/25881#p-57882-protocol-fee-rollout-4) 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](https://www.arc.io/blog/arc-mainnet-goes-live-on-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](https://github.com/Uniswap/protocol-fees/blob/main/script/proposal-4/Index.md#wormhole-context). 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](https://gov.uniswap.org/t/temp-check-activate-v4-protocol-fees/26162). v2 and v3 protocol fee levels are the same as on all other chains where fees are live. See a breakdown [here](https://developers.uniswap.org/docs/protocols/protocol-fee/concepts/fees#fee-split-table). ## 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. ```auto 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](https://app.notion.com/p/uniswaplabs/acp-Uniswap-Standard-Chartered-3ddc52b2548b8103afdce63993c7469c). The second call sends the fee activation calls to Arc: ```auto WORMHOLE_SENDER.sendMessage(targets, values, datas, UNISWAP_WORMHOLE_RECEIVER, ARC_WORMHOLE_CHAIN_ID) ``` encoding: ```auto 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](https://www.arcexplorer.org/address/0x89e5DB8B5aA49aA85AC63f691524311AEB649eba) | Uniswap V2 Factory | | V3\_FACTORY | Arc | [0xf0db7b58379503491d857dB50AC9ece64c653918](https://www.arcexplorer.org/address/0xf0db7b58379503491d857dB50AC9ece64c653918) | Uniswap V3 Factory | | V4\_POOL\_MANAGER | Arc | [0x8366a39CC670B4001A1121B8F6A443A643e40951](https://www.arcexplorer.org/address/0x8366a39CC670B4001A1121B8F6A443A643e40951) | Uniswap V4 Pool Manager | | UNISWAP\_WORMHOLE\_RECEIVER | Arc | [0xbCA30b5429935205037069cF5b8A165F55d05a75](https://www.arcexplorer.org/address/0xbCA30b5429935205037069cF5b8A165F55d05a75) | Governance owned Wormhole receiver | | TOKEN\_JAR | Arc | [0xfd39ac616e630e9db03EFB2c9a4Fe63eDB949233](https://explorer.arc.io/address/0xfd39ac616e630e9db03EFB2c9a4Fe63eDB949233) | Fee Collector | | V3\_OPEN\_FEE\_ADAPTER | Arc | [0xa59FfbB55D91Fc32b44A06F0b9cc6036a4afbcE2](https://explorer.arc.io/address/0xa59FfbB55D91Fc32b44A06F0b9cc6036a4afbcE2) | Uniswap V3 Fee Adapter | | V4\_FEE\_ADAPTER | Arc | [0x2f2bd3F43880b9644211f16d861b0672aaB23782](https://explorer.arc.io/address/0x2f2bd3F43880b9644211f16d861b0672aaB23782) | Uniswap V4 Fee Adapter | | V4\_FEE\_POLICY | Arc | [0x9671B518dA771c5c73d8115b3800FA7653a72015](https://explorer.arc.io/address/0x9671B518dA771c5c73d8115b3800FA7653a72015) | Uniswap V4 Fee Policy | | RELEASER | Arc | [0xe1Adf3f130Abf616a7aB04AEeBf8D0470F6B6a16](https://explorer.arc.io/address/0xe1Adf3f130Abf616a7aB04AEeBf8D0470F6B6a16) | WormholeReleaser | | NTT\_MANAGER | Arc | [0xcaABe9866eb34178922651d6e51e414B29174A31](https://explorer.arc.io/address/0xcaABe9866eb34178922651d6e51e414B29174A31) | Wormhole NTT Manager | | WORMHOLE\_TRANSCEIVER | Arc | [0x06e8bdE95BE4ce5cB1134BD47aD18a79fFB35822](https://explorer.arc.io/address/0x06e8bdE95BE4ce5cB1134BD47aD18a79fFB35822) | Wormhole Transceiver | | SYNTHETIC\_NTT\_UNI | Arc | [0x0ff2262B299D2a7784Cfb29f944FbAB239Ad1df6](https://explorer.arc.io/address/0x0ff2262B299D2a7784Cfb29f944FbAB239Ad1df6) | Synthetic UNI | | WORMHOLE\_SENDER | Ethereum | [0xf5F4496219F31CDCBa6130B5402873624585615a](https://etherscan.io/address/0xf5F4496219F31CDCBa6130B5402873624585615a) | Wormhole Sender | | NTT\_MANAGER | Ethereum | [0x6569925Aac77D6B8Bb085F31F9828ff80D5a0c44](https://etherscan.io/address/0x6569925Aac77D6B8Bb085F31F9828ff80D5a0c44) | Wormhole NTT Manager | | WORMHOLE\_TRANSCEIVER | Ethereum | [0x7597C40Fd3df66b750C14ad4D90524e247499011](https://etherscan.io/address/0x7597C40Fd3df66b750C14ad4D90524e247499011) | Wormhole Transceiver | ## Next Steps / Timeline - **Snapshot:** Sep 18-23, 2026 - **Onchain vote:** Following successful Snapshot ---
**Author:** ![Anzus\_GemWallet](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/anzus_gemwallet/32/10641_2.png) [@Anzus\_GemWallet](https://gov.uniswap.org/u/Anzus_GemWallet)\ **Post date:** [September 21, 2026, 12:26pm UTC](https://gov.uniswap.org/t/temp-check-protocol-fee-expansion-arc/26287/2 "2026-09-21T12:26:32Z")
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. ---
**Author:** ![UniswapLabs](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/uniswaplabs/32/5196_2.png) [@UniswapLabs](https://gov.uniswap.org/u/UniswapLabs)\ **Post date:** [September 21, 2026, 8:26pm UTC](https://gov.uniswap.org/t/temp-check-protocol-fee-expansion-arc/26287/3 "2026-09-21T20:26:47Z")
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. ---
**Author:** ![Anzus\_GemWallet](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/anzus_gemwallet/32/10641_2.png) [@Anzus\_GemWallet](https://gov.uniswap.org/u/Anzus_GemWallet)\ **Post date:** [September 22, 2026, 3:09am UTC](https://gov.uniswap.org/t/temp-check-protocol-fee-expansion-arc/26287/4 "2026-09-22T03:09:42Z")
Thanks for clarifying and pointing to Base as a reference. I’ll pass this along to our team for our Arc fee explanations. ---
**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:** [September 23, 2026, 10:29am UTC](https://gov.uniswap.org/t/temp-check-protocol-fee-expansion-arc/26287/5 "2026-09-23T10:29:45Z")
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. ---
**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:** [October 1, 2026, 6:13pm UTC](https://gov.uniswap.org/t/temp-check-protocol-fee-expansion-arc/26287/6 "2026-10-01T18:13:15Z")
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. ---
**Author:** ![martineza79](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/martineza79/32/10691_2.png) [@martineza79](https://gov.uniswap.org/u/martineza79)\ **Post date:** [October 5, 2026, 2:04pm UTC](https://gov.uniswap.org/t/temp-check-protocol-fee-expansion-arc/26287/7 "2026-10-05T14:04:28Z")
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?