I am proposing the integration of a comprehensive transaction simulation feature into the existing MultiversX wallets.
Currently, there is a concern among users about the lack of visibility into the outcomes of their transactions within MultiversX. While it has been noted that full transaction simulation is possible through node-level APIs, there is an opportunity to significantly improve user confidence and trust in the platform by integrating this simulation directly into the wallets.
Objective:
The primary goal of this feature proposal is to empower MultiversX users, with the ability to simulate transactions before confirming them. This enhancement will provide users with a clear understanding of the expected outcomes of their transactions, fostering transparency and building trust in the MultiversX ecosystem.
Key Features/Ideas:
Transaction Simulation Integration:
Implement a user-friendly transaction simulation feature within the MultiversX wallets, allowing users to preview the outcome of their transactions before finalizing them. The simulation should cover all relevant details, such as gas fees, estimated time of transaction (due to the nature of MultiverX’s sharded architecture), token transfers, potential contract interactions, and any other pertinent information related to the transaction.
Scam Prevention Benefits:
The transaction simulation can play a significant role in scam prevention. By allowing users to preview and understand the details of their transactions before confirming, this feature acts as a powerful tool to identify potential scam attempts. Users can verify the legitimacy of transactions, ensuring that they align with their intentions and expectations. This added layer of verification can contribute to a more secure and trustworthy MultiversX ecosystem.
XPortal Mobile App Focus:
Tailor the transaction simulation feature to seamlessly integrate with the XPortal mobile app, ensuring a consistent and intuitive user experience across devices.
Optimize the simulation for mobile screens, considering the limited real estate and touch-based interactions.
User Education and Guidance:
Develop in-app guides or tooltips to educate users on how to effectively utilize the transaction simulation feature.
Provide clear explanations of the simulated results, helping users interpret the information and make informed decisions.
Emphasize within the educational materials and the feature itself that the simulation is a representation and not an actual execution. Users should be aware that real-world factors might influence the final outcome, and the simulation is intended for informative purposes.
Ledger integration:
Ledger integration needs some additional thought and could be done subsequentially. Users could still use MultiversX web wallet integration in the meantime.
Integration into MultiversX ecosystem components / dapps:
Ensure seamless integration with other MultiversX ecosystem components / dapps, to offer a unified and cohesive user experience when using a ledger.
In other words: Make the simulation available in dapps.
Conclusion:
The integration of a transaction simulation feature directly into MultiversX wallets will not only address current user concerns but also position MultiversX as a leader in providing a transparent, user-centric, and secure blockchain experience. This feature aligns seamlessly with MultiversX’s commitment to innovation, user empowerment, and enhanced security measures.
By enhancing transparency and offering a user-friendly experience, this feature will not only empower users to prevent potential scams but also ensure that MultiversX remains at the forefront of providing a seamless and trustworthy environment.
Thank you for considering this proposal, and I am eager to discuss any further details or questions you may have.
When writing this, one slightly off-topic thing that came to my mind, maybe a core dev like @robert could answer me:
Would it technically be possible with MVX’s current (or future) architecture to allow a user set specific output expectations in the future and if the transaction does NOT give these expected outputs, roll everything back on the protocol level?
Like for example:
A user starts a transaction to a dust converter with 15 input tokens, and the dapp preselects an expected minimum outcome of 0.15 wEGLD for this transactions. When signing this transaction, this will be embedded into the transaction data and if only 0.14 wEGLD will come back, the protocol will rollback everything.
This would guarantee, that the user gets what they signed up for.
But my current idea of the architecture is that it’s impossible due to how shards work, right?
There is some similarity, but you cannot compare it at all with the thing, that we currently understand under the term “slippage”.
Slippage is a feature by a smart contract. Slippage doesn’t actually prevent a smart contract to do bad stuff. You have to trust the smart contract to do what it says it does.
What I was refering to is something way more sophisticated than just slippage. It’s a guarantee of a given output. “Give me this or give me back my damn tokens”, an ensurance that the sc does exactly what you want him to do, and nothing less.
Who would “run” the simulation for the transaction execution?
The main problems I see with a simulation are the following:
Someone needs to execute the simulation, and the simulation does not have a fee. So someone needs to do operations (which many time are intensive) without earning anything in return. This system would not be sustainable with a lot of users doing it from the wallet by default for every transaction, unless the cost is on the user (either a fee or the simulation happens on his machine)
Even when there is no fee for simulation, but more so if there is one, then users expect that the results of the simulation will be the same also for the real execution, which cannot be guaranteed. The execution context evolves with each round/block, and depends also on external events to the known system at the moment of simulation (other users and their interactions).
So I would explore first the options on who does the simulation:
Have the api provider support the cost - this is the current setting, but not by default integrated for any user transactions, as the wallet uses “free APIs” and it would not scale for a large number of transactions and would increase too much the costs.
Have the wallet client (on the user side) handle the simulation - this would be quite heavy to be done on the client, as it needs to have a large part of logic that is implemented on a regular node in the network brought to the client (the gas metering, execution logic from protocol, the VM, contract(s) and state that the execution touches for that transaction) and this in my opinion is not currently feasible, and even if it were, it would probably also give you a probable outcome, not a definite one due to the evolving context I mentioned above.
All observers already have an endpoint to run such a simulation
Hm this can happen too, sure!
Users should not expect this, because as the name suggests, it’s a simulation.
I think the main usecase for these simulations will be to detect if you will be scammed or not by a malicious contract. And for this, this will be definitely good enough and execution will not depend on rounds or blocks or other external factors here
The part regarding it being “just an estimate and not the actual result” is very acceptable for me personally. It would still give you a rough idea about what you can expect to receive from the SC.
Other startup chains like Radix show you a guaranteed transaction summary before you actually send the transaction, so you basically can’t get scammed and you dont have to trust any SC at all to actually give you, what you expect.
In an optimal mvx world, my transaction would fail and everything will be rolled back, if I dont get my expected result. But this is impossible, due to its sharded architeture MVX is currently running with. Personally, I think the simulation could be compromise, IF we find solutions for the operational costs you mentioned.
Do not confuse what sharding is doing. It is not impossible.
On the mainnet, since the launch of the mainnet, everything is rolled back by default if your expected results are not what you want, even in cross shard. In a DEX you set up a slippage, even if it is cross shard, if the trade does not go through, everything is reverted back.
Also you can do full preexecutions, same as in any other non-sharded systems.
Yes, we know about Radix showing it out, what Adrian mentioned it is that those simulations have a computational cost, and somebody has to pay for those servers. In case of Radix, and even in the case of MultiversX webWallet and xPortal, these cost would be paid by the MultiversX team. These costs are not small, >20KUSD per month. But it does not mean that we will not do it.
I mean, crazy idea, but what if you try to lower the costs by doing one of the following:
Give access to this feature only to people who pay for it
Each address has a maximum of 10/20/30 simulations it can do per day
A simulation has to get triggered by the user, it does not happen automatically, the user has to click a button for it to happen. If it happens automatically everytime even for simple things, it will cost a lot of money
Don’t do simulations for staking/delegating/unstaking/unbonding/normal transfer of EGLD/normal transfer of ESDT
Just a few ideas of what could be done.
MultiversX Foundation has started to introduce new revenue streams (xMoney, xFabric, Cards, …) I feel like we should leverage this. Make stuff more efficient
Actually we may have a new lead in this, where the simulation can be run on the user’s device leveraging WASM microservices. We have to prioritise the things we implement. It was added to backlog.
It will still have some bigger downsides, scamming will still be possibile using random (like only scam 1/2th of the time), but this would be huge start and a great addition!
Not sure, how hard it will be to detect, that an evil SC uses “random”-functions to scam, but I’m sure xAI can help in the future with analyzing the wasm
