Crypto exchanges has provided an easy access to crypto for the regular users, they constitute the majority of the trading volumes happening. One of the core features they offer for its users is crypto deposit and withdrawal, which plays a role in allowing the users to freely move their assets without any hurdles, at anytime 24/7. But that comes with a cost especially for crypto deposits, since majority of CEXs provide a unique deposit address for each of its users, to allow them to deposit into their platform, and credit their account, once the transaction has been confirmed, to allow for the exchange to keep the liquidity easy to manage whenever they want to rebalance or process a withdrawal, the exchange has to forward the deposited native token (e.g. ETH) or an ERC20 token to the exchange main wallets, which incur a lot of cost which might be challenging especially when the exchange is new to the market.

GLOSSARY:

CEX: Centralized Exchange.

ETH: Ether, Ethereum native token

ERC20: Ethereum Request for Comment 20; a standard that defines fungible token.

EVM: Ethereum Virtual Machine.

EOA: External Owned Account.

Multisig: A smart contract wallet, that provides the users with additional security, because it requires multiple user’s signatures, for the transaction to take place.

PROBLEM BACKGROUND:

The approach being adopted by most CEXs in handling crypto deposits has multiple advantages:

• Easy UX: allows users to easily and predictably deposit into their associated address, knowing that the exchange will be able to process their deposit and credit their account at all times without any issues.

• Common address across EVM-compatible blockchains: Most CEXs provide a unique address that can be used across EVM-compatible blockchain (e.g. Polygon, BSC…).

• No extra cost for the user: When the deposit is made, once the block confirmation passes, the user’s account is accredited the crypto without any extra cost on their account for any internal operational cost.

Meanwhile, there are multiple drawbacks that this approach imposes:

• CEX operational cost: Once a deposit is made into the user associated address, the latter initially will not have any native token for gas costs, once the amount to be forwarded meets a certain threshold would require the platform to send native token as the first transaction, then followed by another transaction to transfer the deposited native token or ERC20 token back to the exchange main wallet, which would at least cost the exchange 42000 gas cost on every eligible deposit. Not to mention the asymmetrical gas cost; the user would only have to pay for a single transfer, while the exchange would have to pay for 2 transactions.

• False-positive fraudulent deposits: Since one of the main goals of exchanges is to ensure adherence to international laws and policies, there are on-chain monitoring for illegal activities such as funds originated from Tornado Cash, which can be used by random users to send dust tokens to associated crypto deposit addresses, which would lead for the CEX account to be frozen for suspicious activities.

  PROPOSED SOLUTION:

  To tackle forementioned challenges faced by the classic approach would be by centralizing the deposits into a single crypto wallet, which the depositer’s address is able to cryptographically sign and register it to their CEX account, each address would be associated at most with a single account to limit the attack vectors.

  To elaborate more, the following flowchart would elaborate more on the process flow:

To remove the associated address, the user would need to login to his CEX account and remove it manually from there without the need of any approval, which would make it available to be registered by any other CEX account.

LIMITATIONS AND OVERCOMES:

The beforementioned solution comes with a limitation, kudos to the chad Pcaversaccio for pointing it out. which is that it wouldn’t work with deposits originating from smart contracts which can impose a challenge in itself. A possible solution is in the case it matches for a multisig interface, it can rely on the owner’s addresses and threshold needed to validate for the minimum signatures needed to register that multisig under that CEX account for deposits. While if it’s not a multisig, we may use the deployer address as a signer who is responsible in registering the smart contract, or defining a common ERC interface which can be implemented and used to get the EOA owner address which can register the contract under their CEX account, it can use owner() function which is used by most existing ownable contracts.

CONCLUSION:

The proposed solution could improve a lot on the security and hugely reduce the maintenance costs for the CEXs as it’s something that is constantly needed to be maintained and factored in the costs to ensure the platform profitability especially for small exchanges. Which also would open the door for the exchanges to spend it on development, research and other areas which can bring greater value for the end-users.

That’s a wrap!