[Bug] Relayed token approval is reported as insufficient after confirming
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
- 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. - On Arbitrum, start a USDC to ETH swap from an account where USDC has not yet been approved for Permit2.
- Submit the USDC approval when Uniswap prompts for it.
- Wait for the relayed transaction to confirm.
- Check the allowance on-chain. The approval has succeeded and Permit2 has the requested allowance.
- 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
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:
checkApprovalAmount then treats that outer calldata as an ERC-20 approval:
The approval parser reads the final calldata words without checking the function selector:
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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