Crypto addresses pool Ethereum

[celizo]

Hello,

Our problematic: we have 10'000 clients and we want to provide one crypto address (lifetime) for each client.

I don't know exactly how crypto exchanges manage their deposit addresses pool for Ethereum ERC-20 for instance (and how to avoid huge fees!).
For Bitcoin/Litecoin, it's easy to have 100, 1000, 10000+ or more addresses based on a master xpub/ypub and provide one address for each client.

The problem with ERC-20 token (USDT/USDC...) is that you can provide one Ethereum address, but you will need ETH in order to pay the fees for forwarding the balance to a central address.

We have tried to create smart contract deposit addresses, such as described in this coinbase page :
https://blog.coinbase.com/usdc-payment-processing-in-coinbase-commerce-b1af1c82fb0
However, fees are huge (I've deployed a test on TRON and it's important too) for deploying/creating only one deposit address.

Apparently, Binance/Kraken don't use smart contract addresses but normal Ethereum addresses for deposits (and they have no ETH on these addresses).
Probably, they forward token balances with a delegation system (fees paid by another Ethereum address)!?

If you have any information about how to manage this, I'll be happy to exchange about the possibilities.

 

[JohnLocke]

Sorry if this is stupid but the last 6 months at least we have had the same address for 5 different cryptos where people do the payment to. That's to our kraken account.

 

[celizo]

Admin, our goal is to have one address for one client lifetime.
In order to authentify and credit automatically all deposits done.

it's impossible to do this with Kraken if you have lots of clients (due to the limitation/expiration of 5 addresses per 5 addresses to create).
It's possible to have several addresses with Coinbase API (deposits addresses unlimited) but with an important activity it's a problem with Coinbase.

However, our goal is to have our own addresses, not Coinbase/Kraken addresses.

 

[legrant]

Admin, our goal is to have one address for one client lifetime.
In order to authentify and credit automatically all deposits done.

it's impossible to do this with Kraken if you have lots of clients (due to the limitation/expiration of 5 addresses per 5 addresses to create).
It's possible to have several addresses with Coinbase API (deposits addresses unlimited) but with an important activity it's a problem with Coinbase.

However, our goal is to have our own addresses, not Coinbase/Kraken addresses.

You can generate an unlimited amount of addresses using an hd wallet, that means, creating unlimited addresses from the same seed.

And when it comes to the fees, I don't think there's much you can do about it. You can batch outgoing transactions but I don't think you can do it the other way around.

 

[celizo]

Thanks a lot legrant, it's the better solution indeed to use an HD wallet.

Yes, we cannot avoid fees, but we want to avoid the double fees (one for funding [ETH] the deposit address + one for forwarding ERC-20 tokens to a cold wallet for instance).

I will try this solution.

It seems the problem will remain the same with HD wallet, because childs will need ETH too.

 

[legrant]

Thanks a lot legrant, it's the better solution indeed to use an HD wallet.

Yes, we cannot avoid fees, but we want to avoid the double fees (one for funding [ETH] the deposit address + one for forwarding ERC-20 tokens to a cold wallet for instance).

I will try this solution.

It seems the problem will remain the same with HD wallet, because childs will need ETH too.

I don't think you'll be able to accomplish what you're looking for unless you're ready to pay all those fees. If it's just ETH, fees will be high but not as high as an ERC20 token.

There are three solutions I can think of:

1) Keep users funds in their own wallets and only send them to your "main" wallet once a minimum amount of $ is deposited on that ETH address. This means you will need to have a lot of crypto in your main wallet to cover all those deposits in case they want to withdraw. When it comes to the fees, you need to have higher withdrawal fees to cover both the withdrawal and eventual transfer of their tokens to the main wallet.

2) Have a minimum deposit amount, let's say $250 so whenever you get a deposit, you send some ETH to that wallet and then send back to the sites "main" wallet. This will probably be easier to handle and it can be combined with the solution above. It will also required high withdrawal fees (depending on network).

3) Have only 1 address and make users input the address they'll be sending from, the token, and the amount they'll be sending. This way you only have one "main" address and all users will deposit there, you can then split the funds into other cold wallets, hot wallets, etc easily and way cheaper. This will be annoying to the clients though because they'll have to input all that information and a small mistake could lead to funds not showing up on their accounts, more support tickets, etc. However, this is probably the cheapest way to do it.

Forgot to mention that the withdrawals could happen every X time (12h, 1 day, etc), that way you could batch them and it'll cost you less.

 

[celizo]

Thanks again, there are others solutions to your 3 points, such as asking clients to use random decimals in order to identify each transaction, or to use a small pool (10-20 rolling addresses funded with ETH - and with a timeframe such as Bitpay/Coinbase commerce...etc), but unfortunately these solutions are not enough straightforward for clients.

Currently I see only 2 solutions for a system with one address per client:

1/ with smart contracts as explained here:
https://ethereum.stackexchange.com/questions/64686/collecting-erc20-balances-from-multiple-addressesor
https://blog.coinbase.com/usdc-payment-processing-in-coinbase-commerce-b1af1c82fb0#e539
2/ with "normal" ethereum addresses, and using a delegation for fees payments.
i.e. GitHub - Enigmatic331/DelegateTestToken-Deployer: ERC20 with signed transfer - Allows token sends where transferor do not need to hold ether, a third party deployer pays gas.

 

[legrant]

Yeah, those two could work too. I'm not an expert in smart contracts so I can't really recommend you anything related to them, my solutions were more of "simple (and probably not efficient) but it works" methods. I wish you luck and if you find a proper solution, don't forget to post it here so others won't have the same issues in the future.

 

[sonato]

I wish you luck and if you find a proper solution, don't forget to post it here so others won't have the same issues in the future.

would be nice of you to do so if you are still around