Uniswap Labs supports The Merge and does not have plans to support any forks in our web app. The move from proof of work (PoW) to proof of stake (PoS) serves as an important stepping stone to scaling the Ethereum ecosystem and to reducing its environmental footprint immediately. If you want to learn more about The Merge, check out Ethereum’s announcement.
As a Uniswap Protocol user, you do not need to do anything. The Uniswap Protocol will continue to work without issue through this transition. The web app (app.uniswap.org) will also continue to function, though if any of our third-party infrastructure providers (e.g. node providers) have downtime, some users may experience brief periods of unavailability.
For those of you building on top of Ethereum, we would like to share two PSAs to keep the web3 ecosystem as safe as possible:
Change in Uniswap v3 TWAP oracle security
Uniswap v3 oracles were designed with PoW security tradeoffs in mind, where it’s predictably difficult for a single entity to mine multiple blocks in a row. In PoS, block producers are announced up front every epoch — which is 6 minutes long. This "look-ahead" means that the cost of manipulating two consecutive oracle values can be significantly lower than in PoW. As an example, the validator for block N could pay a premium in gas to control the last transaction in block N-1, knowing that they control the order of transactions in the next block. In the context of time weighted average price (TWAP) oracles, this would give them a window to manipulate by changing the price to a very high or low value to influence the average.
It’s worth noting that validators are selected randomly. However, a large validator pool can also randomly be selected to produce two or more blocks in a row. Given the size of some of the larger pools, this could be a frequent occurrence and also open up the ability for a validator to manipulate oracle prices by, again, predictably controlling two or more blocks in a row.
We recommend considering this additional attack vector when relying on TWAP oracle in Uniswap Protocol v3. If you are looking for workarounds, Median Oracle implementation by the Euler team is a solid implementation to explore.
Replayability for permits
Permits are an alternative to approves — where a user can allow another contract to spend a token on their behalf. Permits save gas by skipping the approve step, allowing users to simply create a cryptographic signature off-chain indicating their consent.
However, some permit implementations (including DAI, USDC, UNI, and v2 LP tokens) include a hardcoded chain ID of 1 when signing a permit transaction. In the event of a chain fork, the new chain ID is ignored. This creates a novel signature replay vector, where a permit to allow a specific address to spend on a user’s behalf can be replayed on the forked chain.
For example, a permit signed for a Uniswap Router on ETH can be used for same router, deployed on the same address on ETHPoW. This is not a risk, as the Uniswap Router isn’t capable of moving any funds from your wallet without an additional authorizing transaction. However, if there was a malicious contract deployed on ETHPoW to the same address, it could reuse the signed permit from ETH to move funds on ETHPoW without user’s permission.
As always, we suggest only signing permits for contracts you trust. If you participate in ETHPoW, we suggest extra due diligence.
These are ultimately small issues and well worth navigating given the benefits to the overall ecosystem. We are excited and looking forward to The Merge!