The problem: It is possible for a new user to create a wallet, have funds, but no EGLD, e.g.:
User bridges USDC/USDT/BTC/ETH/UTK/INFRA from Ethereum to his new MultiversX wallet. He will have USDC/USDT/BTC/ETH/UTK/INFRA on his wallet but 0 EGLD.
User buys MEX with an on-ramp solution for his new MultiversX wallet. He will have MEX on his wallet but 0 EGLD.
User withdraws UTK from Binance to his new MultiversX wallet. He will have UTK on his wallet but 0 EGLD.
In all these cases, the user has funds but no EGLD, and so he is stuck. He canât do anything because he has no EGLD to pay the gas for any action. In particular, he canât swap his funds to EGLD because he has no EGLD to do so.
This is quite painful to get unstuck. You either need to buy EGLD with an on-ramp solution or need to go on a centralized exchange to buy EGLD and then withdraw it to your wallet.
A solution: Allowing gasless swaps to EGLD for wallets that have not made any transaction yet.
Because the situation where a wallet has funds in his wallet but no EGLD only happens once in the wallet history, this should not cost much to the relayer.
If costs were to be too big for the relayer, a small fee could be charged on the output EGLD to reimburse the relayer.
Just to have an idea, a simple swap costs about 0.0004 EGLD or $0,01 now, a multipair swap about 0.0012 EGLD or $0,03 now.
A number that at the top of the previous bullrun was 20 times higher. If today this represents a very small sum indeed, in bullrun it could perhaps become a problem if all arbitrage bots took this feature into account to decrease their break-even thresholds.
This would probably greatly increase the number of new accounts created per day, and TPS such as high-frequency arbitrage would be more easily profitable. It can seems interesting for on-chain statistics, but can be dangerous in terms of risk of liquidity extracting from the xExchange.
Since this sum is almost insignificant for users who would find themselves in the situations you mentioned, I think it will always be preferable to tax these features on output EGLDs.
The ideal would be to change the router contract (or create a new contract) that takes a cut on the EGLD output. This way, this canât be gamed. However, it requires more time to develop and might not be necessary in the short term feature.
So a plan could be:
on the short term future, while swap fee is low and arbitrage bots donât abuse (at current price, 0.03$ wonât change much the break-even point for them), we can just setup a relayer and pay.
on the long term future, we will definitely need to add / change a smart contract to take a fee on the EGLD output to prevent gaming or too high costs.
Totally agree, I donât think this will be a problem now, just a necessity in the future.
As implementing the cut off on the output requires more devellopement effort, implementing the relay now may be a good idea!
On the other hand, I wonder if these kinds of events are frequent enough to become a priority now.
Which leads to a topic that will be important to discuss in the coming weeks imo, that would maybe to share what the team is working on at the moment, what your time capacity is to build xEIPs in addition to developments already underway, but also to understand your vision on futur devellopement and try to discuss with the community where we need to focus our brain power for the coming months !
This would also avoid starting work on subjects that might conflict with what youâre already working on.
At some point in the future it would probably make more sense to be done at the xPortal level by receiving something like 0.0015 eGLD or less as a âWelcomeâ for a new user, but only after completing some onboarding steps (to prevent abuse).
I think it can also help with onboarding people outside of crypto space by removing the first interaction friction of having to buy eGLD before making any move on the blockchain.
Some examples I can think of rn (as a first blockchain interaction):
I receive an NFT as a gift from friends or as an incentive to join the ecosystem, but I canât send it to anyone or list it on a marketplace.
I paid for my friends meal/drink at a restaurant and they want to pay me back in USDC (or other future stable). Now I have USDC, but canât move it without eGLD.
Itâs not xExchange related (only gasless txs related), so sorry for the offtopic
In the case of swaps, is there no way that the relay fee to create this âgasless transactionâ for an end user be paid (through reinbursement to the relay wallet) from the initial token they are swapping from?
Example (values are illustrative only):
User has 100 UTK, but no EGLD
Wants to swap 50 UTK to EGLD
For ease assume 100UTK = 1EGLD
A relay transaction from an xExchange controlled wallet pays for the gas fee
Swap = 50UTK â 0.48EGLD (0.01EGLD is slipping and LP fees, the other is bounced over to a relay wallet)
This would allow for that ease of use in the circumstances you illustrated, whilst curbing potential botting/exploitation/arbitrage due to the higher spread on the swap.
@xfoudres This will probably happen once in the lifetime of a user, so will be rare but will be very painful when it happens. Also, I was just sharing an idea, implying nothing on the priority.
@martzos Who would be paying the 0.0015 eGLD? In the proposed idea, the user would still be paying the gas fee without needing EGLD upfront.
@x89 Not sure to understand what you mean by âfrom the initial token they are swapping fromâ. In your example, the fee seems to be taken on the EGLD output. Your example is exactly what will happen if the idea is implemented.
@lucaswillems
xPortal could find a model to cover these costs with the help of the existing users.
For example some mission tasks in the Play section could have an option to be completed by paying a small fee (maybe the Invite friends & family one or any other).
For 1.000.000 new users the cost would be 1500 EGLD. Some of these new users will also generate funds to cover this process.
Itâs just an idea Iâm exploring and it has more to do with expanding xPortal to mainstream, marketing strategies and oboarding/keeping new users and less with xExchange, so itâs a bit offtopic.
Coming back to the proposed idea, I think it would be good to have the fee charged on the output EGLD or, if possible, even the option to choose on what end the fee will be paid at any time, regardless of the tx history of the wallet.
I would be surprised and slightly baffled that anyone would create a MultiversX wallet without any intention of buying EGLD to fund it. This is a non issue imo and no way worth any effort.
I can only think of 1 case where this might need attention and that is where you have a siloed blockchain with only a bridge and no external CEX or DEX solutions to buy a native coin and transfer in. Nice to be considerate but its a no from me
The problem: It is possible for a new user to create a wallet, have funds, but no EGLD, e.g.:
User bridges USDC/USDT/BTC/ETH/UTK/INFRA from Ethereum to his new MultiversX wallet. He will have USDC/USDT/BTC/ETH/UTK/INFRA on his wallet but 0 EGLD.
User buys MEX with an on-ramp solution for his new MultiversX wallet. He will have MEX on his wallet but 0 EGLD.
User withdraws UTK from Binance to his new MultiversX wallet. He will have UTK on his wallet but 0 EGLD.
@erd13cfvs_srqwtnerp Have you never encountered one of these cases? For having onboarded multiple people on MultiversX (especially people from other blockchains), this is very frequent. They are stuck because they have bridge USDC but donât have EGLD and so I have to send them some EGLD.
This is imo a functionality that ought to be abstracted and a configurable option by e.g. the sdk-dapp.
Separately, taxing output funds of such operations also sounds useful for such purposes. For this, the sdk-rs would need to expose information about the relayer with its API
Good that xExchange is in tight cooperation with these teams
A dApp for onboarding could work by having users provide data or perform traditional user tasks in order to âapplyâ for initial gas funding. This would take the problem away from governance and avoid bots while providing an option that could help all parties. Question is: is it worth the effort?
