I'm building a dApp that involves creating unique accounts for individual users for ERC20 deposits [I keep the addresses and private keys in a centralized database], for popular ERC20 tokens like BNB, 0x, etc. However, to function, my dApp needs to collect all these balances into a central wallet. Since these are ERC20 deposits and not ETH deposits, the user wallets have no ETH deposited in them and therefore will have no way to pay for the gas to send their ERC20 balances to the central wallet.
Does anyone know an efficient solution to this problem? My naive solution is to just send ETH into a user's wallet every time I detect an ERC20 deposit into that wallet, so that said wallet can pay for the gas to transfer, but this is ugly and seems like a lot of overhead in gas.
Thanks!
Best Answer
There are two ways this is done today:
1. Normal Accounts
Generate wallet keys / addresses that your users transfer to, and you have to send gas to those addresses in order to move funds.
Downsides:
2. Smart Contract Accounts
Deploy a smart contract factory that generates a "receiving address" that the main "account can control".
In essence you have a smart contract that creates new addresses that store received funds, and you have an "owner" address that can call a method to transfer funds.
There are multiple ways you can implement this:
The Factory contract, can implement ownership validation and control the receivers, or each receiver could do the validation itself.
Best implementation, security and performance wise i can think of is the following:
Factory contract:
Batching is important if you want to lower gas usage and implement hardware signing
Think about having a separate server that does the signing, you could even have an external hardware wallet plugged into this, or an HSM ( Hardware signing module ).
The awesome part here is that you can even implement this in such a way that you can collect tokens from any Ethereum based smart contract / token tracker ( BNB / DAI / etc. ) or any token standard using a custom caller interface ( you can call arbitrary methods at any address you want ).
No need to send gas to these receivers as the owner is the one "sending the transaction" and the "receiver contract is the owner of the tokens"
Cheap gas for deploying and interacting with receivers, since you can do it when the network is not congested, as well as the ability to integrate with GasToken ( gastoken.io ) to lower your price even more.
Hope this helps.
Sample Starting Code
TODO
Flow: