I'm working on a project that can be seen as a centralized exchange. We already have support for Solana deposits/withdrawals and I now I'm adding support for token deposit/withdrawals, but with this, some concerns popped up. For the usual use case, user deposits funds to their deposit address, we will sweep the funds to our hotwallet that will always have Solana and will always be rent exempt, and this is great. But it could happen that a user sends unsupported tokens to the deposit address ( we won't detect this ), and that deposit address won't have any solana and we also won't detect it.

This can be a huge problem, let's say we have support for BONK and we receive like 1 million usdc tokens, and for what I've seen around, an account that isn't rent exempt could have the data erased from the network, and this could mean that the funds are lost. I see that the rent collection happens in two phases, when referenced by a transaction and periodically once an epoch. Once an epoch is kinda dangerous no ? Since they happen every 3 days...

How can I deal with this issue ? Funding every deposit address account is not valid. Can't find good information anywhere about how long would it take to erase an account data from the network, etc. Already tried Discord but no one seems to know much about this. Thanks guys

  • how are you creating the user specific "deposit addresses"? Are each of these specific to each token or specific to a user?
    – nickfrosty
    Jan 19 at 17:35
  • Hey nick, thanks for the reply. Deposit addresses are related to a specific user, but if the token is not whitelisted on our platform, we won't detect it. So we can say that the deposit address is only one for the whole solana network.
    – gumminho
    Jan 19 at 17:59

3 Answers 3


Plz take a look on Associated Token Account The token account will always be rent-exempt because it’s created by a program.

  • I'm not sure because the user deposits address is already generated... probably won't be the best idea to have new addresses
    – gumminho
    Jan 22 at 10:14

Update: We can conclude that every time we make a token transaction, if the destination address is empty, the sender address will have to fund the creation of the associated token account ( this concept is present on every token transaction, and you can't bypass this step, and this account is rent exempt always ). So, when an empty address receives funds there is never the danger of the funds being wiped out.


Even if someone was to send any tokens that are "unsupported" by your exchange, the tokens would not be lost. They would just stay at the final destination's "associated token account"

The way that token ownership works on Solana is using these "associated token accounts" ("ATA" for short) is like this:

When anyone transfers tokens to a wallet address (i.e. your user's "deposit address"), the tokens would be actually deposited into the user's associated token account for the respective token mint.

If this user's ATA does not already exists, the sender of the tokens will actually pay the Solana "rent" (aka data storage) fee and create the ATA. This will make it so the actual user that owns the ATA can always transfer the tokens at their discretion.

So in the exact case you mention in your question, it would work like this:

  • your exchange has user specific "deposit addresses" (userAccount)
  • when any sender wallet (senderAccount) transfers the Bonk token to the userAccount, the Solana token program will check if the associated token account for Bonk, owned by the userAccount exists (userBonkAta)
    • if the userBonkAta already exists => the transfer happens and the userAddress now has more Bonk token. the sender will pay just the transaction fee
    • if userBonkAta does NOT already exists => the senderAccount will pay the transaction fee AND the rent/storage cost to create the userBonkAta
  • when your exchange want's to "sweep" the supported tokens, you still can the same way you are already doing it (with only your supported tokens)
  • the tokens that your exchange does not "support" will just remain in the userAccount's wallet. no harm no foul

In the end, your exchange service would not be paying the extra cost to create these ATA's for each token type. It would be the sender/depositor.

Note: In fact, from a product development standpoint, you could even periodically check your user's "deposit accounts" for large amounts of any token and maybe decide to add support for that token. Just a thought though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.