Metamask-extension: Pending transaction from a side chain was executed on the mainnet
Describe the bug
I was using the xDAI POA side chain and my transaction was pending for several days. After changing to the mainnet and launch a new transaction, my previous side chain transaction was executed.
To Reproduce
Not sure I am able to reproduce it again.
I was using xdai.io burner wallet, which uses the xDAI POA sidechain. Somehow the transaction was not going through and stays in the pending state on my wallet. When moving to the mainnet, the pending transaction was still there.
I then executed a new transaction on the mainnet, and suddenly my pending transactions from the side chain were executed. Therefore some ethers went to a unknown address and got lost forever!
Expected behavior
Transactions from private RPCs should not be mixed in the list of transactions on the mainnet
Screenshots
Tx link: https://etherscan.io/tx/0x20d1787d23ff345b64314559294f03f06e2f8d23e79037709d3ab7778959939c
Browser details (please complete the following information):
- OS: OS X
- Browser: Chrome
- MetaMask Version: 5.0.2
joaoaguiam
All 18 comments
I experienced the exact same issue using xDAI POA side chain with a custom RPC on https://dai.poa.network. xDai pending transactions resolved on the Ethereum main net when I changed the Metamask selector to main net.
The transactions should not be sent if I change my RPC.
OS: Linux Ubuntu 16.04
Browser: Chrome
Metamask Version: 5.0.2
riusricardo
on 20 Nov 2018
Hi all, sorry for the slow reply. If you're able to reproduce this, please contact us at [email protected] so we can get some logs to help us diagnose how this could happen.
danfinlay
on 12 Dec 2018
Hi @danfinlay , this issue just happened to me again, I had a transaction that was rejected or pending (not sure which state) on the xDai POA side chain, and when I moved to the Mainnet and executed another transaction, the one from the POA side chain was executed on the mainnet.
The failed transaction didn't have much value luckily, otherwise, it would have been lost.
Here is the transaction on the mainnet: https://etherscan.io/tx/0xec77021ae69a93cc4f6a72bfaa6f90d98f35b0c813aa5733f160379b3d9c3a3d
Metamask version: 5.3.1
Feel free to contact me on telegram at @joaoaguiam to help you debugging.
joaoaguiam
on 28 Jan 2019
I think that the issue is still there. @joaoaguiam next time, you should try by sending the pending transaction into a test net. I haven't tried to use an xDai advanced custom RPC. But my guess is that if we create a new custom RPC with network id under advance preferences, the issue will probably be mitigated.
I think that it keeps pending because of the transaction gas. We need to get deeper into this issue, and create some replication steps.
A related issue was reported in the burner-wallet repo: https://github.com/austintgriffith/burner-wallet/issues/82
@joaoaguiam as far as I can see, you where playing with the Burner token.
https://blockscout.com/poa/dai/tokens/0xdec31651bec1fbbff392aa7de956d6ee4559498b/token_transfers
https://blockscout.com/poa/dai/address/0xdec31651bec1fbbff392aa7de956d6ee4559498b/transactions
riusricardo
on 28 Jan 2019
it's possible if the xDAI POA has the same netID and chainID as ethereum main net it is possible for the pending tx to be submitted to the ethereum main net. do you have a url enpoint i could use for xDAI POA chain?
frankiebee
on 28 Jan 2019
^ @joaoaguiam
frankiebee
on 28 Jan 2019
oh scratch that found one
frankiebee
on 28 Jan 2019
Ethereum mainnet -> 1
https://dai.poa.network聽-> 100
https://core.poa.network聽-> 99
https://sokol.poa.network聽-> 77
I don't think it is the case. xDai is 100.
riusricardo
on 28 Jan 2019
yeah just confirmed that
frankiebee
on 28 Jan 2019
might be related to https://github.com/MetaMask/metamask-extension/issues/5956
frankiebee
on 28 Jan 2019
@riusricardo Yes I was playing with the Burner Wallet and Burn token.
I didn't set the chain id when I added the xDai RPC. Do you think if this is set to 100 there should be no issue?
Next time it fails I will move to the test net then. Thanks!
joaoaguiam
on 29 Jan 2019
@joaoaguiam just make sure you don't have more than 1 custom rpc in your list. Remove all RPCs and only use one Custom RPC in metamask for now.
rstormsf
on 29 Jan 2019
Remove all RPCs and only use one Custom RPC in metamask for now.
If that's a user-side workaround, we should just make add custom rpc overwrite any existing rpc, to do the same programmatically. @frankiebee
danfinlay
on 29 Jan 2019
I have two custom rpc indeed, but just allow one rpc is very limiting in my opinion.
joaoaguiam
on 30 Jan 2019
@joaoaguiam
Hopefully this PR fixes this issue
https://github.com/MetaMask/metamask-extension/pull/6044
Please let us know
rstormsf
on 30 Jan 2019
Remove all RPCs and only use one Custom RPC in metamask for now.
@joaoaguiam @danfinlay that is not an effective workaround; best to just put the chain Id in settings when you use the rpc till the new update has reached all users
the update will not be able to fix miss-assigned chainID's so you will still need to reenter them on the new update if they have a cached value that is incorrect.
frankiebee
on 31 Jan 2019
This should be fixed in v5.3.4, let us know if not!
danfinlay
on 1 Feb 2019
Thanks for the fix 馃憤
If I fall on the same problem I will let you know here!
joaoaguiam
on 1 Feb 2019
Related issues
glitch003
路
3Comments
DISC30
路
3Comments
danfinlay
路
3Comments
aecc
路
3Comments
kumavis
路
3Comments
Most helpful comment
@joaoaguiam @danfinlay that is not an effective workaround; best to just put the chain Id in settings when you use the rpc till the new update has reached all users
the update will not be able to fix miss-assigned chainID's so you will still need to reenter them on the new update if they have a cached value that is incorrect.