Simple steps to transfer USDT without ETH in your wallet

I heard this like million times from the devs, who were trying to build really smooth and simple user flow in the Web3 space - I want to create a wallet for my users, where they will receive tokens like USDT or NFTs, and I want them to be able to transfer them anytime. But, this is not simply possible on most EVM networks - as I described in the posts before, if you want to make a transaction of any kind on the EVM network, you must pay the gas connected to it. The gas is paid only in the native token of the network, e.g., ETH or MATIC. But here is the problem - your users must possess ETH on their wallets to transfer anything to a different wallet. So, what choice do developers have to solve this issue? I will describe some most known setups and how to tackle them.

Non-custodial dApp

💡

Decentralized, or non-custodial applications, are the type of apps where no one except the end user - owner of the wallet - can perform any actions with the blockchain assets on their wallets.

With the non-custodial dApp approach, you have 2 options for how to manage transfers of the assets from the wallet.

Send ETH to the address

Send ETH to the address and cover the costs. This is the most straightforward approach, but it has many downsides. Imagine that your dApp onboards thousands of new users who are new to the blockchain space. You will distribute them your NFTs or tokens of any kind, and then you ask them to fund their wallet with some ETH to withdraw it. This is so UX unfriendly that it can't be worse 😊.

You will either force them to buy crypto on some exchange, which might be impossible for them due to local regulations in their country or you, as a dApp provider, must send them tokens to their addresses before they want to do the transfer. The second approach is more viable, I have seen that in a couple of projects, but sooner or later, they changed that. It was easy to maintain the ETH distribution when they had 100 or even 1000 users, but with tens of thousands of users, they could not send the ETH fast enough.

Use Account Abstraction principles

Use a very new technique, which is called Account Abstraction (AA). This new approach enables the developers to build a wallet for their users so that the gas cost can be covered by someone else or it can be paid in the ERC-20 tokens like USDT or USDC. I will dive deep into the AA in future posts because it is a very interesting approach for solving more complex issues.

Custodial dApp

💡

Custodial dApps are defined as those where the application provider manages control over the blockchain wallet. It means end users of the dApp do not own the private keys to the wallets that hold the blockchain assets. It means that whenever the provider decides to shut down the service without previous notice, the assets held by the customers are locked on their platform.

With the custodial dApp approach, there are many more ways to tackle the problem of not having the ETH on the user's wallets. The reason why is super simple: you, as a provider of the dApp with full control over the wallets of your users, can do anything with the assets on it - transfer them between different wallets, create the wallets as a smart contract instead of a regular public/private key pair, automatically redirect the incoming deposits to a central wallet, etc...

Transfer ETH to the use wallet

This is the same principle as I described above, and it's the same ineffective one.

Use Account Abstraction

Again, the same principles and mechanisms as described above.

Create a smart contract instead of a wallet

Create a wallet for your user as a smart contract instead of a regular address. This approach gives you the benefits of implementing a custom logic, which should be done when a USDT or NFT comes to the wallet. The 2 most common use cases here could be:

Auto forwarding wallet - this type of wallet transfers every incoming deposit to a specific address upon arrival. The owner of a wallet actually never owns anything on the wallet - everything is transferred to a central place. This will lead to the fact that the central dApp wallet provider owns all tokens and assets. When the users of the dApp would love to withdraw the assets, they are sent from the central place. It means that this central wallet must own the ETH to fuel the transactions. But they are sitting in a single wallet, which is super simple to maintain and keep track of the balance.

💡

The downside of this approach is that the initiator of the transaction must pay higher transaction costs to be able to transfer the assets to the wallet - because the sender is the one who is paying the forward transfer to another wallet.
Gas pump wallet - this type of smart contract wallet holds all the assets that arrive at it. But only the approved and pre-defined wallet owner can transfer them out. During the creation of a wallet, the owner is defined, and that address is the one that pays all the gas costs for any transfer from the wallet. Again, ETH assets must be held at the owner's address, but this approach keeps the assets present in the wallet, so for the end users, it's easier to check the wallet's balance on the blockchain explorer.

Summary

There are, of course, many more ways to solve this problem. There are EVM-compatible blockchains where paying the gas cost is a built-in feature of that chain (Klaytn or Arbitrum). Some other chains, like Solana, support the external fee-payer mechanism by default, which is a crucial thing for building a simple UX for the end users. I will cover the non-EVM ecosystem in future posts, so stay tuned. 🚀🚀🚀