UniswapX Audit

The UniswapX Protocol operates as a non-custodial trading framework based on Dutch auctions. It seamlessly combines on-chain and off-chain liquidity, protects swappers from MEV by making them participants via price enhancement, and enables gas-less swaps. Traders create signed orders detailing their swap requirements, while participants known as fillers employ arbitrary strategies to fulfill these orders by competing with each other.

UniswapX leverages Permit2, a token approval contract introducing signature-based approvals and transfers for ERC-20 tokens without the need for them to be compliant with EIP-2612. Swappers must approve the Permit2 contract first for each token, but this only needs to be done once. After that, instead of self-submitting transactions, they sign orders which are shared via API to a network of fillers (MEV searchers, market makers, or other on-chain agents). Fillers send them to a specific reactor contract, which settles orders ensuring that trade execution aligns with user expectations and reverts non-compliant trades. The gas-less experience for the swapper is achieved because the fillers are the ones submitting orders on-chain, covering the gas fees on their behalf. This cost is recouped, in addition to a small profit on the trade itself, by factoring it into the execution price.

UniswapX incorporates the logic to manage three distinct order types by providing three different reactor contracts, each of which presents its own unique fulfilment rules.

When fillers execute an order, they have a chance to revert at the end of their callback if the trade was not profitable for them. However, the executeWithCallback flow (and its batch equivalent) does not end right after the callback. Instead, once the callback is over, the output balances are transferred from the filler to the swapper by the reactor.

If one of the output tokens is either a malicious ERC-20 implementation controlled by the swapper or a legitimate ERC-777 implementation, the swapper can receive one more callback within the transferFrom function call to perform arbitrary operations. These operations might be gas intensive and will be funded by the filler. At this point, the filler has no more execution control. As such, given a high enough overall transaction gas limit, even if a profit was made on the trade, the filler could incur a loss.

A malicious swapper might use this technique to perform a legitimate swap as well as let the filler subsidize a potentially gas-intensive operation (e.g., minting gas tokens on applicable chains, performing more swaps, deploying contracts, etc).

Consider adding a final callback to the filler to allow reverts if a profit was not made after fees. This will turn this vector into a griefing attack since the filler will be charged for the revert, but at least the swapper will not profit from the filler. In order to make the extra callback more gas efficient, consider either making it optional or having the filler call an external version of _fill as the last step on their callback. It is imperative to ensure the filler has called the _fill function, but this must be done without checking the balances of the recipients.

The CurrencyLibrary is used to handle ERC-20 tokens and native currency transfers in UniswapX. The native transfer is performed with a low-level call without calldata and a hard-coded gas limit of 6900.

Gas limits on calls are considered a bad practice for two main reasons:

       • Gas costs have changed over time (e.g., as per EIP-1884).
       • EVM side-chains and L2s can have different gas costs. This has previously caused funds to           become stuck as transfers run out of gas and revert.

Both arguments could lead to unreliable functionality over time and across chains. A smart contract wallet can have logic in its receive or fallback function which exceeds the 6900 gas limit, thereby disabling that wallet to use the service for swaps where the native currency is involved. Furthermore, the protocol injects fees into the orders that are sent to the fee recipient, including ETH. Hence, a fee vault or a multi-sig wallet as a fee recipient can be equally affected by this problem.

Note that the concern of reentrancy should be tackled at the entry point level, which was not identified as a risk for this scope. Further, for the concern regarding the swapper being able to spend the filler's gas maliciously, please see M-01.

Consider removing the gas limitation to guarantee the functionality of smart contract wallets when engaging with UniswapX.

The contracts in the codebase are using the floating pragma ^0.8.0 . This version indicates that any compiler version starting from 0.8.0 can be used to compile the source code.

The protocol allows fees to be collected. To do so, a protocol fee controller needs to be set to a non-zero address. Uniswap governance has the ability to collect up to 0.05% of the token amounts, as enforced by the ProtocolFees contract. The FeeController is queried by the ProtocolFees contract to get a list of fees that need to be taken, specifying the amounts, the token addresses, and the recipients.

Any mistakes in that return value will cause the _injectFees function to revert if:

       • The fee token is not part of the original order.
       • The fee is too large.
       • There is a duplicated entry.

Since the fees are fetched for every order from any reactor, an incorrect response will halt all trading activity. This can be the result of an attack or a bug in the fee controller.

If this is not intended behavior, consider not charging fees when one of the above cases occurs in order to not affect trading activity. Instead of reverting, an event can be emitted and be caught by a monitoring solution.

The Dutch order implements a linear decay function. From decayStartTime to decayEndTime the amount of input or output tokens goes from startAmount (best rate for swapper) to endAmount (worst rate the swapper agrees with).

However, in the current implementation, it is possible to provide the same value for the decayStartTime and decayEndTime . In this case, the Dutch order is acting like a limit order as the final amount will not change gradually over time. Instead, the final amount will be equal to the endAmount, which ambiguously benefits the filler over the swapper.

Consider changing the price of Dutch orders without duration to be equal to the startAmount instead of the endAmount by swapping the two else-if blocks checking that the timeframe is in favor of the swapper. Alternatively, consider restricting the usage of Dutch orders to actual Dutch orders with a non-zero duration and price decay.

Consider either using or removing any unused named return variables.

Consider removing unused imports to improve the overall clarity and readability of the codebase.

Consider addressing the following typographical errors:

Every swap through UniswapX can charge a fee on the input and output tokens. As per the documentation, this fee must not exceed 0.05% "of the order outputs". This is checked by accumulating the input and output token amounts per token address and calculating whether the fee amount is within the 0.05% threshold.

When swapping a token for itself, such as when bridging it from one chain to another (assuming the same token address and value), the token amount would be doubled through the accumulation. Hence, a double fee could be erroneously charged.

Consider handling this specific case such that only the input or the output amount is taken into account when calculating the fee.

While audits help in identifying code-level issues in the current implementation and potentially the code deployed in production, the Uniswap team is encouraged to consider incorporating monitoring activities in the production environment. Ongoing monitoring of deployed contracts helps identify potential threats and issues affecting production environments. With the goal of providing a complete security assessment, the monitoring recommendations section raises several actions addressing trust assumptions and out-of-scope components that can benefit from on-chain monitoring.

Access Control

Medium: Regarding issue L-02, consider monitoring the ProtocolFeeControllerSet event to track when FeeController address has been changed unexpectedly. While this means that the account has been compromised, in the audited version a malicious change could manipulate the returning fees and thereby halt the trading activity.

Technical

Low: Regarding the recommendation of L-02, if an event is implemented as a reaction to a wrong fee, consider monitoring it to be alerted about bugs in the FeeController.

Suspicious Activity

Medium: Consider monitoring the parametrization of orders for outlier detection. Activity outside the norm, such as a rapid linear decay or no duration (see L-03), can indicate malicious intent by the quoter to trick the swapper in signing an adverse order to make an exceptional profit. Note that due to the inherent filler competition this is rather applicable for exclusive Dutch orders.

Low: As of now, the allowed order reactors in UniswapX need to be explicitly enabled. In the future, this restriction may be lifted, allowing for arbitrary reactor contracts to be used. Consider monitoring that these reactors do not pose a threat for swappers or fillers if they are injected maliciously.