Metamask Unity Plugin shows different Ethereum amount for user confirmation on Metamask mobile wallet than that requested by Unity

Developer Discussion
1

I am integrating the MetaMask Unity Plugin given on Unity Asset Store and followed the github documentation, to allow users to connect their MetaMask mobile wallet app with my Windows Unity app, and for authorizing transactions.

I was testing transactions on the Sepolia testnet
I edited this snippet provided in their docs and the demo_class provided in their Unity package:

var wallet = MetaMaskUnity.Instance.Wallet;
var transactionParams = new MetaMaskTranscation
{
    To = "0xd00..................................a",
    From = MetaMaskUnity.Instance.Wallet.SelectedAddress,
    Value = "0x0" //------------------------> note
};

var request = new MetaMaskEthereumRequest
{
    Method = "eth_sendTransaction",
    Parameters = new MetaMaskTranscation[] { transactionParams }
};
await wallet.Request(request);

I modified the receiving address and the value to be sent. The wallet is connected and transactions are working, except for the incorrect amount shown and transferred to the receiver. I understand that the value requested from the plugin is in wei, whereas that shown in the mobile app will show ether amounts greater than 0.00001 eth. For the smaller amounts, I needed to confirm from the block explorer.

For the following txRequests the Mobile Wallet shows corresponding amounts in the popup request.

Sent Request           Received Request     Gas Fee       Total
1000000000000          0.00028            + 0.000032    = 0.000313
10000000000000         0.00045            + 0.000032    = 0.004536
100000000000000        0.07206            + 0.000032    = 0.007209

I do not understand this conversion, since as I understood once, 1 wei = 10^-18

2

Hi Naruto :slight_smile:

I think I found the bug you are facing and a workaround that you can use for now. The value field is always read as hex currently. Entering the value 1000000000000 will result in the app encoding it as 0x1000000000000 which is equal to 281474976710656 in decimal. This matches the behavior you’re seeing

However this should be fixed, since the intended behavior should be to interpret as decimal if it doesn’t have a 0x prefix. Contract interaction and this API in general has some improvements coming as well :hammer:

2 Likes
3

Yes I got that… Currently passing hex values of my decimals to make it work.

1 Like
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.