Closed hilmarx closed 2 years ago
Hey all! Half of our users come through MM mobile and this issue is directly affecting them, as well.
@hilmarx are you sure this is caused by appending bytes to the encoded transfer payload? We are experiencing the same issue it seems. Whenever we try to transfer an amount, MM mobile says it's a transfer. But when you accept the tranfer, it tries to deploy a new contract. When inspecting the transaction, the payload is fine, but it seems the to address has been set to undefined indeed, resulting in a failed contract deployment.
However, we aren't appending anything to the payload (as far as I know). We also only have this issue on mobile. On web it works as it should. For reference, we're using WalletConnect to connect to MM and do the transfer.
Hope this thing can be fixed/cleared up soon, as MM is used by a lot of users.
@MaartenWeber14 thanks for your comment, you are right, I added an EDIT to my original comment above.
Is there any updates or workarounds?
Yeah would also be keen to get an update on this!
Still affected by this bug and appreciate any workarounds as it is directly preventing Mobile users from using a portion of a platform.
Appreciate any workarounds or updates on this issue
It's very important issue. No updates yet?
It still have this problem when send token erc20 through walletconnect service by web3js. Anyone have solution for that?
This bug is so serious, please update ASAP. Anyone have any temporary solution for this?
Following up to see if this has been addressed yet. This is impacting countless users.
Hi this issue has been plaguing me for weeks, it would be great if we could solve this soon. For now I have to use my PC each time to do this same thing I enjoy on mobile.
This issue is caused by code that substitute value
and to
transaction properties by encoded transfer data(this one)
The easiest fix is to introduce case insensitive search here because contract map has vary case keys.
Possible fix
// `to` is lowercased on line #316
let asset = props.tokens.find(({ address }) => address.toLowerCase() === to);
if (!asset) {
// try to lookup contract by lowercased address `to`
asset = contractMap[Object.keys(contractMap).find(key => key.toLowerCase() === to) || ''];
if (!asset) {
try {
asset = {};
asset.decimals = await AssetsContractController.getTokenDecimals(to);
asset.symbol = await AssetsContractController.getAssetSymbol(to);
// adding `to` here as well
asset.to = to;
} catch (e) {
// This could fail when requesting a transfer in other network
// adding `to` here as well
asset = { symbol: 'ERC20', decimals: new BN(0), to: to };
}
}
}
PS My dApp is affected when try to submit transaction via WalletConnect
facing same issue
same issue. waiting for a solution.
This is a very serious problem why not solve it first?😅
Treat this ticket to represent the 1st issue; @gantunesr will create a separate ticket for the 2nd issue. ]
Estimation for this ticket represents the 1st issue.
same issue. waiting for a solution.
any news ?
the problem is too fatal!
Big number issue? Community? +1
Any news ? this is a huge problem and should be easy to fix
@Hilmarx @MaartenWeber14
Thanks to your investigation and clarification with the last section of the ticket description:
v3.2.0
)v3.3.0
)Issue 1) If you append data to the e.g. transfer payload, the displayed values of how will be transferred get completely scrambled as seen in the screenshots of my original comment above.
Issue 2) If you use sendTransaction, even if you dont append any extra bytes to the payload, the to address is interpreted as undefined and a contract gets deployed instead of the to address being the ERC20 token.
Thank you for your patience and understanding. Pls keep an eye for the version updates in the next 2-4 weeks, and let us know if you encounter these issues again after upgrading to these version(s) starting mid next week.
sweet!
Thanks for the update! Looking forward to it.
Describe the bug:
When sending transactions on Ethereum, e.g. an ERC
transfer
, you can appendbytes
to the encodedtransfer
payload. This is used by dApps toenrich
the information of certain transactions with additional data. In our case, it is used to later verify on-chain that certain data which was appended to a regular ERC20 transfer was indeed signed by the user or not.It can look something like this:
On desktop using Metamask or any other wallet, this works fine. However on Metamask mobile, the extra data which was appended to the regular erc20 encoded data seems to completely mess with the transaction, leading to the amount to be transferred to be completely messed up (Very dangerous) and the
to
field being undefined, resulting in the transaction trying to deploy a contract.Screenshots
How it should look like:![IMG_1733](https://user-images.githubusercontent.com/19579480/120624210-bf47f280-c460-11eb-8152-30caeb08bca9.PNG)
How it actually looks like:![IMG_1732](https://user-images.githubusercontent.com/19579480/120624223-c2db7980-c460-11eb-89a3-dfc500b6fd82.PNG)
=> Sending this transaction will result in a contract being deployed which fails.
To Reproduce Check out this codebase of using
sendTransaction
with a regular erc20 transfer payload (without appended data):https://github.com/gelatodigital/sorbet-finance/blob/288c42f1dbb786d510265b95aad0cff164a47607/src/components/ExchangePage/index.jsx#L617-L625
You can try it out here: https://sorbet-finance-git-fix-metamask-mobile-bug-gelato.vercel.app
It works fine, however defeats the purpose of the dApp (we need to append some additional payload to the
data
)Now, check out this codebase, where we do append additional payload to the data field: https://github.com/gelatodigital/sorbet-finance/blob/fe8e198d5d2d4c32d0a838b6b9e696c5bd04e496/src/components/ExchangePage/index.jsx#L617-L630
You can try it out here: https://sorbet-finance-git-fix-metamask-mobile-bug-2-gelato.vercel.app
There you will see the bug occurs. As mentioned before, on Web Metamask and using other Wallets such as Formatic, it works fine. This issue also occurs on Mainnet, not only Matic.
Smartphone
EDIT:
Replying to @MaartenWeber14 comment.
I just checked again and I think you are right, I am talking about two separate issues here.
Issue 1) If you append data to the e.g.
transfer
payload, the displayed values of how will be transferred get completely scrambled as seen in the screenshots of my original comment above.Issue 2) If you use
sendTransaction
, even if you dont append any extra bytes to the payload, theto
address is interpreted as undefined and a contract gets deployed instead of theto
address being the ERC20 token.