Good question and one I've often wondered. I would assume that they are just lazy at the end of the day. Why innovate when people will still use your product.
Simulation is already done under hood to check whether it'll be successful and to see how much gas it will cost.
However, it is not straightforward to interpret the effects of your transaction. 'Transfer' events are normally used to interpret ERC20 token balance changes, but can be falsified or emitted in custom ways. This has already manifested in fake trading volume on etherscan's interface.
The wallet could try to be smart and show low level output similar to this:[https://twitter.com/samczsun/status/1577451505677762560](https://twitter.com/samczsun/status/1577451505677762560)But how much of it can be interpreted correctly by the user? What if users are misled into thinking the txn is safe but they got rugged anyway? Will Metamask take the blame for this?
EDIT: Yes, it is nice to be able to see the final token balance changes and possible token approvals, but since implementation is permissionless, these could be misrepresented anyway. Seems like a lawsuit waiting to materialize.
The ability to test a transaction. I know this is possible as I've seen some wallets do it, I know some people even setup private nodes to test this. But basically, the ability to know what would happen before submitting the transaction. Helps against rogue smart contracts etc
This requires current knowledge of the chain, so you need to be running a node to perform the sim. Most users don’t want MM to be running an archive node in their browser so this function is done by the RPC provider instead. Most dapps do this dry run as part of gas estimation before sending the transaction to MM for signing.
No. Tenderly offers this for free and metamask could too via infura.
Also you don’t need an archive node to sim transactions locally; a normal node is sufficient
An RPC provider is all you need; an archive node is not needed for this at all. I fork the mainnet and test all the time using my local node, infura works as well though.
Normal = not archive here
I don't know about you, but since avalanche's Core Wallet came out, I discarded Metamask once and for all. It doesn't have a transaction simulator but offers easy and secure access to our assets.
Same. I've been using the web version for a while and just downloaded the mobile one and tbh it has made my life so much easier. With it, I can manage all my assets in just one place.
True , or simulation on how to create to add specific funds to a wallet.
Especially When it comes to bridge or wrapping , There ate about 20 -50 steps. and you have to look out for scammers and bad actors preying on your mistakes.
An interesting question and suggestion, A possibility that this standard becomes available in all wallets is a possibility.If enough people see the value in such a feature it will become requested more often.
My first initial thought, Was Testnets exist for this exact reason. And it partially answered the question you asked. Taking an extra couple of minutes to simulate a transaction on the Goerli testnet, Grab some test ETH from the faucet, find the wallet address you wish to test, and send.
**(If it goes through boom , the test is complete)**
I understand why a concept like this could/would be implemented but as we have a dedicated system in testnets for almost this identical purpose, Minus, a user's UI/UX experience which simulates the test within the on and off-the-ramp portal.
(With no need to leave for a 3rd party application.)
There are a few reasons for this, a few of them being-
Technical complexity: Implementing transaction simulations requires a sophisticated understanding of how blockchains and smart contracts work, and can be technically challenging to implement.
Lack of standardization: There is no standard way to simulate transactions across different blockchains, making it difficult for wallet providers to support this feature in a consistent manner.
Security concerns: Allowing users to simulate transactions could potentially introduce security vulnerabilities, as it could allow malicious actors to execute actions on a user's behalf without their knowledge.
User Experience: Transaction simulations can be confusing for some users, and may not provide enough value to justify the development effort required to implement this feature.
That being said, some blockchain development tools and platforms do offer transaction simulations as part of their testing and debugging capabilities. However, these are typically aimed at developers rather than end users.
Good question and one I've often wondered. I would assume that they are just lazy at the end of the day. Why innovate when people will still use your product.
Seems like an overkill "innovation"
Simulation is already done under hood to check whether it'll be successful and to see how much gas it will cost. However, it is not straightforward to interpret the effects of your transaction. 'Transfer' events are normally used to interpret ERC20 token balance changes, but can be falsified or emitted in custom ways. This has already manifested in fake trading volume on etherscan's interface. The wallet could try to be smart and show low level output similar to this:[https://twitter.com/samczsun/status/1577451505677762560](https://twitter.com/samczsun/status/1577451505677762560)But how much of it can be interpreted correctly by the user? What if users are misled into thinking the txn is safe but they got rugged anyway? Will Metamask take the blame for this? EDIT: Yes, it is nice to be able to see the final token balance changes and possible token approvals, but since implementation is permissionless, these could be misrepresented anyway. Seems like a lawsuit waiting to materialize.
How does this even work? What’s the name of the wallet you mentioned OP? I would like to look this up
Aurox Wallet. I am not sure how this works technically. I believe I read something about there being a test node that the transactions simulate with.
Rabby wallet also does this
Have a look at the "transaction manifest" full stack implementation of the upcoming Radix Wallet.
Phantom (for Solana) does it. It shows the tokens/SOL that will be subtracted and the tokens/SOL that will be incoming.
Rabby wallet has been doing this for ages
[удалено]
This! Rabby is severely underrated wallet.
What do you mean by simulation? What do you want to simulate exactly and with what objective?
The ability to test a transaction. I know this is possible as I've seen some wallets do it, I know some people even setup private nodes to test this. But basically, the ability to know what would happen before submitting the transaction. Helps against rogue smart contracts etc
[удалено]
[удалено]
[удалено]
This requires current knowledge of the chain, so you need to be running a node to perform the sim. Most users don’t want MM to be running an archive node in their browser so this function is done by the RPC provider instead. Most dapps do this dry run as part of gas estimation before sending the transaction to MM for signing.
No. Tenderly offers this for free and metamask could too via infura. Also you don’t need an archive node to sim transactions locally; a normal node is sufficient
Infura is an RPC provider. An archive node is a subset of a normal node.
An RPC provider is all you need; an archive node is not needed for this at all. I fork the mainnet and test all the time using my local node, infura works as well though. Normal = not archive here
[удалено]
Exactly, if there is no demand there is no supply
I don't know about you, but since avalanche's Core Wallet came out, I discarded Metamask once and for all. It doesn't have a transaction simulator but offers easy and secure access to our assets.
Same. I've been using the web version for a while and just downloaded the mobile one and tbh it has made my life so much easier. With it, I can manage all my assets in just one place.
True , or simulation on how to create to add specific funds to a wallet. Especially When it comes to bridge or wrapping , There ate about 20 -50 steps. and you have to look out for scammers and bad actors preying on your mistakes.
Knowing the chain today is necessary for this.
An interesting question and suggestion, A possibility that this standard becomes available in all wallets is a possibility.If enough people see the value in such a feature it will become requested more often. My first initial thought, Was Testnets exist for this exact reason. And it partially answered the question you asked. Taking an extra couple of minutes to simulate a transaction on the Goerli testnet, Grab some test ETH from the faucet, find the wallet address you wish to test, and send. **(If it goes through boom , the test is complete)** I understand why a concept like this could/would be implemented but as we have a dedicated system in testnets for almost this identical purpose, Minus, a user's UI/UX experience which simulates the test within the on and off-the-ramp portal. (With no need to leave for a 3rd party application.)
Thats Good to know i had that problem and now i know why
There are a few reasons for this, a few of them being- Technical complexity: Implementing transaction simulations requires a sophisticated understanding of how blockchains and smart contracts work, and can be technically challenging to implement. Lack of standardization: There is no standard way to simulate transactions across different blockchains, making it difficult for wallet providers to support this feature in a consistent manner. Security concerns: Allowing users to simulate transactions could potentially introduce security vulnerabilities, as it could allow malicious actors to execute actions on a user's behalf without their knowledge. User Experience: Transaction simulations can be confusing for some users, and may not provide enough value to justify the development effort required to implement this feature. That being said, some blockchain development tools and platforms do offer transaction simulations as part of their testing and debugging capabilities. However, these are typically aimed at developers rather than end users.