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.
When looking at mitigating risk, we’ll want to take in the following considerations:
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:
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.
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:
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.