Our valued sponsor

Crypto addresses pool Ethereum

celizo

Active Member
Sep 14, 2019
130
80
28
Visit site
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 :

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.
 
  • Like
Reactions: sonato
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.
 
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.
 
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.
 
  • Like
Reactions: JohnLocke
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.
 
Last edited:
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.
 
Last edited:
  • Like
Reactions: JohnLocke
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:
or

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.
 
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.
 
  • Like
Reactions: celizo

Latest Threads