You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that safe.global encounters issues when using Uniswap without the integrated app, especially when connecting via WalletConnect. If you skip the sponsored call for the approval transaction (and instead pay the fee with MetaMask), the response will be returned to Uniswap. In Uniswap’s code, there is a check where it takes the transaction data, parses the last 64 characters as the amount, and parses characters 64 to 104 as the spender. This check passes for safe.global, but it appears to be a coincidence. The parsed data is not the correct amount—it just happens to be a large number, which makes the check pass. Additionally, the spender is parsed as the zero address, which is also incorrect.
But what is more interesting is this: Now, when using a sponsored call, the response doesn’t come back at all. What’s even more interesting is that even if the response did come back, the check would fail. This is because the sponsored transaction is constructed in such a way that the amount always ends up being zero due to the trailing zeros in the transaction data.
Environment
Browser: Chrome, Brave
Wallet: MetaMask
Chain: Any chain
Steps to reproduce
Go to safe.global, launch the wallet, connect to Uniswap via WalletConnect, and try swapping ERC tokens. However, ensure that you are approving the token you are swapping for another token for the first time. This is because the approval is for an unlimited amount, and the approval transaction will not occur if you have previously approved the token you are spending.
Expected result
should get a response that approval happened.
Obtained result
permanent loading.
Screenshots
The text was updated successfully, but these errors were encountered:
@Lukk18 For the quickest resolution to your issue, we highly recommend using our live chat support, available 24/7. Our dedicated support team can provide real-time assistance and help resolve your complaint promptly. You can access the live chat here: Help SUPPORT.
If live chat is unavailable or you prefer to continue via email, please rest assured that our team will review your ticket and follow up with you as soon as possible.
@Lukk18 For the quickest resolution to your issue, we highly recommend using our live chat support, available 24/7. Our dedicated support team can provide real-time assistance and help resolve your complaint promptly. You can access the live chat here: Help SUPPORT.
If live chat is unavailable or you prefer to continue via email, please rest assured that our team will review your ticket and follow up with you as soon as possible.
Bug description
It seems that safe.global encounters issues when using Uniswap without the integrated app, especially when connecting via WalletConnect. If you skip the sponsored call for the approval transaction (and instead pay the fee with MetaMask), the response will be returned to Uniswap. In Uniswap’s code, there is a check where it takes the transaction data, parses the last 64 characters as the amount, and parses characters 64 to 104 as the spender. This check passes for safe.global, but it appears to be a coincidence. The parsed data is not the correct amount—it just happens to be a large number, which makes the check pass. Additionally, the spender is parsed as the zero address, which is also incorrect.
But what is more interesting is this:
Now, when using a sponsored call, the response doesn’t come back at all. What’s even more interesting is that even if the response did come back, the check would fail. This is because the sponsored transaction is constructed in such a way that the amount always ends up being zero due to the trailing zeros in the transaction data.
Environment
Steps to reproduce
Expected result
should get a response that approval happened.
Obtained result
permanent loading.
Screenshots
The text was updated successfully, but these errors were encountered: