A budding cryptocurrency exchange has several options when it comes to providing their users with cryptocurrency wallets. They can generate and provision segregated wallets for each user or they can use pooled wallets to achieve a level of scalability. The wallets can be held in an online server or an offline machine, respectively called a hot wallet and a cold wallet.


Segregated Wallets:

  • Keys need to be securely generated for each user; key management is challenging. Every transaction is on chain; transaction costs are high. Settlement coordination is a challenge for in-network transfers. Lower security risk exposure per wallet

Pooled Wallets:

  • Simple key management
  • Transaction costs scale due to periodic settlement
  • Higher exposure and risk

General Concerns

When looking at mitigating risk, we’ll want to take in the following considerations:

  • Reduce the amount held in online funds
  • Allow for the online wallets to hold a sufficient balance to service the exchange

A Comfortable Middle Ground

One popular architecture that allows for pooled wallets while mitigating the risks involved in having online wallets is to use a combination of hot and cold wallets to lower online exposure of funds. Each wallet serves a different purpose. Let’s talk through the different styles of wallets:

  • The receiving wallet serves the purpose of managing incoming funds into the exchange.
  • The sending wallet serves the purpose of managing withdrawals from the exchange.

Both of these wallets are hosted and managed on online servers. Due to the fact that these are both online wallets, we want to minimize the amount of funds we have in these wallets, which will help us reduce the risk of loss of funds if there is a compromise. The cold wallet serves the purpose of managing a majority of the funds so that a compromise of any of the servers does not result in a compromise of a majority of the funds.

How Do They Connect?

Let’s say that the receiving wallet only has a single address and all of the funds coming into the exchange come into that wallet. We will want to send some of those funds offline in order to reduce the exposure of online funds. We will also need to send some funds from the receiving wallet and the cold wallet to the sending wallet on an as need basis. This is to ensure that the sending wallet can adhere to a reasonable level of service on withdrawals. If we run low on the sending wallet and funds aren’t reliably coming into the receiving wallet, then there is the option to move funds from cold storage to the sending wallet.

Let’s layer in some basic logic to help us mitigate the risk. As an example, let’s say that the exchange on average has 100 BTC in assets on hand and that at any point in time, we don’t want to risk more than 30% of our funds. We can set our overall minimum and maximum thresholds per wallet to help account for this risk. Here’s how the logic would pan out:

  • Receiving — The wallet is not to have more than 10 BTC on hand at any moment in time. If the sending balance drops below its minimum threshold, the receiving wallet will credit an amount to make it whole. The wallet is not to drop below its minimum amount in case the inflow of funds drops and the sending wallet needs to be made whole. However, if there are excess funds, above the maximum amount, they are sent to the cold storage wallet.
  • Sending — The sending wallet is designed to enable withdrawals to wallets outside of the platform. It needs a minimum amount to be able to service these withdrawals in a timely manner. If this sending wallet drops below its minimum balance requirements, then it requires a transfer from the receiving wallet. If the receiving wallet does not have the requisite funds, then the funds are to be transferred from the cold storage wallet.


Let’s quickly address scalability. Using a single incoming wallet is not the best decision. What we can do to address this simply is to use a hierarchical deterministic wallet to generate a unique address per user. This enables the ability to create unique public addresses without having to generate and manage additional key pairs for each user. If you’ve ever built an application using BitcoinD, you know what that feels like.

Let’s say the operation is scaling now, and we’re concerned about having our funds in a single wallet. An upper threshold of ²³²-1 keys can be generated from a single HD wallet. It is also possible to scale horizontally. If funds are coming in at a rapid pace, beyond what was expected, a second receiving wallet that settles into either cold storage or the sending wallet could be added. This concept can be applied broadly to all of the wallets. If we need more sending wallets, adding wallets to scale horizontally in order to limit the amount exposed in a single wallet or server is a solution.

This wallet architecture was highly popular starting in 2015 due to its simplicity for the optionality it provides for scaling. One common concern about the various blockchains out there is the ability to scale; however, most exchanges employ a pooled wallets model, such as the one described here, which enables the architecture to cope better with high on-chain transaction fees. Additionally, it allows organizations to pick their risk profile and to plug in the parameters necessary to meet that risk profile.