Uniswap / Uniswap/interface

[Bug] Relayed token approval is reported as insufficient after confirming

Open
#8,056 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
5.5k
Forks
5.4k
PR merge metrics
No merged PRs in 30d

Description

Interface affected

Uniswap web app, production.

Environment

  • Chrome on macOS
  • Cloaked browser extension
  • Arbitrum One
  • USDC to ETH classic swap

Steps to reproduce

  1. Connect a relayed/smart-account wallet that supports eth_sendTransaction. The wallet should execute the requested call inside an outer contract transaction and return the outer transaction hash.
  2. On Arbitrum, start a USDC to ETH swap from an account where USDC has not yet been approved for Permit2.
  3. Submit the USDC approval when Uniswap prompts for it.
  4. Wait for the relayed transaction to confirm.
  5. Check the allowance on-chain. The approval has succeeded and Permit2 has the requested allowance.
  6. Return to the swap flow.

Expected behavior

Uniswap should recognize that the approval succeeded and continue to the swap.

Actual behavior

Uniswap shows "Insufficient approval amount" and asks the user to retry, even though the approval succeeded on-chain.

Confirmed example

https://arbitrum.blockscout.com/tx/0xaffce46f75ed4c457a024e17a96d3ec0f81e65a3dd89fd871808ffe435c68387

This transaction confirmed successfully and set the USDC allowance for Permit2 to the maximum value. Uniswap still showed the insufficient approval error afterward.

What seems to be happening

The wallet returns the hash of the outer relay transaction. Its calldata is an Orchestrator call rather than the original ERC-20 approve calldata.

handleOnModificationAsync sees that the returned calldata differs from the requested calldata and passes it to checkApprovalAmount:

https://github.com/Uniswap/interface/blob/da6d36f71c4d2fd665b0aae1a052a4ffda917b31/apps/web/src/state/sagas/transactions/utils.ts#L263-L279

checkApprovalAmount then treats that outer calldata as an ERC-20 approval:

https://github.com/Uniswap/interface/blob/da6d36f71c4d2fd665b0aae1a052a4ffda917b31/apps/web/src/state/sagas/transactions/utils.ts#L367-L388

The approval parser reads the final calldata words without checking the function selector:

https://github.com/Uniswap/interface/blob/da6d36f71c4d2fd665b0aae1a052a4ffda917b31/packages/uniswap/src/utils/approvals.ts#L1-L13

In this case, part of the relay calldata is interpreted as the approval amount and triggers ApprovalEditedInWalletError.

It would be safer to run the edited-approval check only when the returned transaction is a direct call to the expected token using the ERC-20 approve selector. For an outer relay transaction, the app could skip this check or verify the resulting allowance after confirmation.

This should affect other relayed wallets that return an outer transaction hash as well, rather than being specific to Cloaked.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with handleOnModificationAsync and checkApprovalAmount in apps/web/src/state/sagas/transactions/utils.ts, then inspect the approval parser in packages/uniswap/src/utils/approvals.ts. Reproduce the relayed approval flow on Arbitrum using the confirmed transaction as a reference. Done means a successful outer relay transaction is not reported as insufficient approval and the swap can continue.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
blockchain, frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
65/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.