Welcome back to the first article in the series on building your own crypto exchange. Asset management and custody are for me the heart of the exchange.
Before we go on, I just want to warn you that building an exchange isn't a walk in the park. If you think you can just hire a bunch of engineers off the internet without the proper guard rails in place for security and compliance, you're asking for a whole world of pain. Also while I know some people may argue with me on this, the fundamentals of building a TradFi online exchange in the cloud still apply to crypto so please do your due diligence.
In this article I’m going to go over the following:
- Custody and security - part 1
- Operations security - part 1
- Risk management - part 2
- Liquidity management - part 2
- Safeguarding of customer funds - part 2
Things I won’t cover right now but will do in the future:
- Cash flow optimisation
- Forecast modelling and reporting
- F/X management
- Regulatory compliance
Custody
Let’s start by going over the options for custody of crypto currencies and digital assets within the business (exchange). At the heart of the exchange you’ll have reserves of assets such as Ethereum, Bitcoin, Solana and Sui etc. These assets are stored separate from customers assets and are used for:
- Strategic business reserves, such as long term holds for investment, capital requirements or even emergency events such as sudden large withdrawals that can’t be modelled, wholesale liquidity providers being down due to Elon tweeting on X (this has happened) etc.
- Managing business liquidity reserves for servicing everyday customer transactions.
- Finally customer reserves, holding customer assets that could be used for trading, exchanging for off-ramping to fiat or transferred out to another wallet.
Generally, for each of these assets you'll have a set of wallets that are usually structured like so:
- Cold -> Warm -> Hot

I’ve seen other variations of this approach in production across various places and projects, but for now, we’ll stick with the explanation above.
Hot Wallets and Omnibus Accounts
One thing to note is that the hot wallet can, but is not limited to, functioning as an omnibus account on the custody side. This means that user assets are co-mingled in a single wallet, while individual balances, transactions, and other details are recorded in a separate ledger—usually off-chain. However, I’ve encountered one case where a private distributed ledger technology (DLT) was used for this purpose.
Omnibus accounts are not your only option, though. Most custody providers also offer the ability to create/manage segregated wallets for each customer via API. There are advantages to this approach, such as improved auditing, the ability to isolate assets, and enhanced traceability—especially useful in cases where someone attempts to launder stolen crypto through your exchange.
Pros and Cons of Segregated Wallets
The downside of using segregated wallets is the additional overhead: you’ll need to manage and track numerous wallets and their associated keys. Furthermore, segregated wallets typically incur higher transaction costs compared to an omnibus wallet. Ultimately, the decision comes down to your specific needs, how you manage risk, and your compliance obligations.
Wallet Setup
- So the value of assets kept in each wallet should generally go left to right as:
- Large -> Medium -> Small
- And frequency of access would be:
- Infrequent -> Frequent -> Most frequent
- And finally gates such as the signers and what can sign on behalf of a user differs also from left to right:
- Cold - transfers to Warm or Hot wallets require the `most number of signers including treasury managers. Usually only undertaken manually and not by automation. Cold wallet only able to transfer to a white listed wallet, usually just the Warm wallet.
- Warm -> Hot - transfers can be signed by machines (application services of the exchange) holding the correct keys, and again transfers can only occur to whitelisted wallets so transfers to an outside wallet from these should not be possible.
- Hot -> - Transfers are initiated out of the exchange by customers and signed by application exchange services (machines), but there are usually gates to help prevent fraud/hacking such as:
- Depending on amount, the exchange can hold the transfer out for a period of time while also notifying the customer.
- Checks against a service like Chainanalysis for transfers outbound transfers to malicious wallet addresses.
- Transaction monitoring. Most exchanges have some bespoke transaction monitoring to catch odd or suspicious behaviour.
- Finally if the exchange exposes MPC wallets to their customers, then the correct number of shares from trusted devices need to be submitted, including the one held by the exchange.
MPC and Multi-sig wallets
I mentioned signers in the plural which is very important not just from a security point of view but also redundancy. Depending on the technology you choose whether multi-sig or MPC can greatly impact your operational risk and cost. For a quick recap on what they are and the difference between them:
- Multi-sig: With a multi-sig wallet, two or more private keys are generated during its creation. The signing quorum, i.e., the number of keys required to sign a transaction, is the same as the number of keys generated during wallet creation. For example, if two private keys are used, both keys are required to sign a transaction. Signing quorum can never change without re-creating a new wallet.
- MPC (multi party computation): Each member of the quorum is provided a share secret, but unlike multi-sig where the secrets are part of the full private key, the shares in MPC are just inputs used by the signing function to generate the signing key. The whole private key is never stored in its entirety.
For any organisation that want, security, resiliency and ultimately to not have security incidents due to user error I highly recommend MPC for the following reasons:
- As previously mentioned, the private key is never stored in its entirety, which eliminates a significant attack vector. With multi-sig, there’s always the issue of private key backup, especially in an era where we’re striving to onboard non-crypto-native individuals into the ecosystem.
- Helps remove single points of failure: Unlike multi-sig, the quorum can be less than the full set of shares. For example, to move funds out of a cold wallet, you might require 3 out of 4 shares held by the Treasury Manager, the CFO, and the COO. If the CFO or COO were unavailable (e.g., due to illness), another individual with access to a share on their device could step in. This approach is based on TSS, or Threshold Signature Scheme.
- Increased security and custom access control: Even if one of the signer’s devices is compromised, the private key cannot be reconstructed. Additionally, it is common to require a higher quorum of approvers for high-value transactions compared to lower-value ones, and MPC can seamlessly facilitate this.
- Usability: As mentioned earlier, asking end users—especially those who are not crypto-native—to back up and secure a seed phrase or private key presents a significant hurdle to widespread adoption, particularly in the enterprise space. By using MPC, both the exchange and the user gain the ability to recover their share in case it becomes corrupted or if their device is lost.
- The way that could work is that the users share could be encrypted by a secret only the user would know and stored on the exchange or custody provider.
- Also this could work with MPC wallets that behave similar to self-custody as the exchanges/custody providers share could be encrypted by a secret only the end user knows, and "unsealing" would require participation of the end user to provide the secret.
- Of course the above sort of negates some of the advantages of MPC because it would still require the user to store the secret somewhere securely.
Something to note, that while MPC is resistant to collusion due to requiring the quorum threshold to be reached, ultimately if all parties collude then it won't save you from this, then again neither would multi-sig save you from this either.
MPC features over single key and multi-sig:
Feature | MPC Wallets | Multi-Sig Wallets | Single-Key Wallets |
---|---|---|---|
Private Key Management | The private key is never constructed in its entirety, reducing attack vectors. | Multiple full private keys are created, each exposed to compromise. | Relies on a single private key, increasing risk of theft or loss. |
Key Backup and Recovery | Enables secure recovery without exposing the private key. | Each private key must be backed up and managed individually. | Requires backing up the entire private key or seed phrase. |
Single Point of Failure | No single point of failure; shares are distributed among participants. | Vulnerable if a sufficient number of keys are compromised. | Entire wallet is compromised if the single key is stolen or lost. |
Quorum Flexibility | Threshold signatures allow a subset of shares to sign transactions. | Static quorum rules (e.g., 2-of-3) must be defined during setup. | No quorum system; transactions require only the single key. |
Blockchain Compatibility | Works across all blockchains without requiring native support. | Requires blockchain-native multi-sig support, limiting compatibility. | Universal compatibility across blockchains. |
Security | Resistant to key compromise since no full key exists. | Vulnerable to collusion or compromise of quorum keys. | Highly vulnerable to single-point compromise. |
Cost Efficiency | No on-chain transaction costs for managing quorum or setup. | On-chain costs for wallet creation and multi-sig transactions. | No additional costs beyond standard transactions. |
Access Control | Allows custom policies, such as dynamic quorum requirements for high-value transactions. | Fixed access control policies defined during setup. | No access control beyond single-key possession. |
Ease of Use | Simplifies user experience by removing the need to manage or backup a private key directly. | Requires users to understand and manage multiple keys. | Simple but risky; users manage a single key or seed phrase. |
Scalability | Scales efficiently for enterprises with multiple users and devices. | Becomes complex with more participants and keys. | Not scalable; suitable only for single-user setups. |
The next key consideration in custody is infrastructure, whether you decide to outsource to a third party or build internally. When dealing with anything cryptographic, unless your organization has in-house expertise and the ability to perform the required audits, I strongly recommend outsourcing to companies like Fireblocks, Copper et al. These providers not only offer MPC (multi-party computation) wallet infrastructure but also include various security and cost-saving features that you would otherwise need to develop yourself.
If, for any reason, you decide to build your own MPC infrastructure, ensure you rely heavily on cloud automation if you’re operating in the cloud, or on automation in general if you’re using your own data centres. Adhere to the principle of least privilege, and I highly recommend implementing a service mesh to establish fine-grained access controls within your Kubernetes (k8s) cluster. Ensure the entire team receive thorough and regular security training and implement the use of passkeys and hardware keys to reduce the risk of social engineering attacks. I'm also a proponent of "Red Teaming" by having dedicated people trying to find vulnerabilities in the platforms, services used and more importantly people. I'll talk a little bit more about security later.
On the software side, I have personal experience with using Rust for MPC infrastructure. Rust’s cryptographic libraries are excellent, hardened, and battle-tested. Moreover, Rust’s features make it easier to write secure software that remains safe at runtime. However, and I cannot stress this enough. You really do need someone with strong experience in cryptography who can test all the edge cases which isn't something most engineers have experience with, including myself.
Ultimately though, I would still recommend people don't try to roll their own. I've done it and knowing all the edge cases I just can't recommend undertaking the task.
Operations security
Something you really need to get a head start on is malicious actors. Now, yes as you’re an exchange hopefully holding a substantial amount in value of assets you will get people externally to the business trying to hack the platform or use the platform in ways to con other unsuspecting users.
In my experience though the biggest threats are always internal to the business which means staff and 3rd party contractors who have privileged access to systems.
Some general of advice should include:
- All staff and contractors should have full background and reference checks without question. It’s a pain I know, including for myself where I’ve spent a significant amount of time in startups that sadly are no longer around.
- No ‘god mode’. While you’ll have systems that allow privileged access and even ‘user impersonation’ abilities via ‘break glass’, you need all access and actions auditable.
- One of the first things I do in any fintech is lock down the infrastructure so that direct access to the production deployment environments is not possible, including any persistence backend.
- For operations tasks you’d be surprised by how many startups think it’s ok to let ops members have direct access to various systems or platforms without fine grained audibility. For a fintech to scale they MUST invest in their tooling on the operations side. Providing tools that are fully auditable, allow of for permissioned access while reducing the time spent on ops tasks is vital. Don’t cheat on this. That old adage of humans being cheaper than software these days isn’t as true as it once was. As soon as you can, you must automate.
- Hire in ‘safe’ countries. Personally, I prefer working in a remote hybrid fashion because I tend to go a little stir-crazy without enough human contact. I also find that the density and efficiency of information transfer are significantly higher in person—something that isn’t often discussed but can be a cheat code for startups. That said, I also need extended periods for deep work, free from interruptions, which is easiest to achieve at home or in a controlled environment with minimal distractions. Because of this, I tend to hire team members who work predominantly remotely but can easily meet in person when we need to kick off a new project or maximize information transfer. Since I currently reside in the UK, I prioritize hiring from countries within a three-hour flight to London. This ensures team members can attend in-person meetings when necessary. Additionally, it provides peace of mind that, in the unlikely event someone went rogue—say, impersonating customers to drain their wallets—I could escalate the matter to local authorities if needed.
- Secret and key management - all staff including senior members of leadership shouldn’t keep secrets or keys locally located in plain text on their devices.
- Use password managers for generating and populating passwords.
- Use infrastructure key management tools and HSM’s including automatic key rotation. This shouldn’t be managed manually.
- Use physical Fido keys to secure account access via MFA. SMS is vulnerable to SIM swap attacks and having an actual physical device makes it way harder for an attacker to gain access as there’s no way for them to replicate this remotely without using social engineering tricks to get the user to disable MFA first.
- Finally although passkeys aren’t perfect, if you can use passkeys instead of passwords then you should.
- Well defined incident response run books.
- Your team should have their laptops hard drives encrypted. If they travel, they should not be travelling to areas of risk or ‘unfriendly’ governments known to utilise hacks in the crypto space for financing their own government operations.
- Regular "Red Teaming" events. A vast majority of incidents are caused by social engineering attacks. Getting the team wary of potential attacks by exposing them to controlled scenarios has been one of the best ways to keep people vigilant.
- Limit your use of 3rd party libraries in your code. You need to verify and every library you use and lock the deployment to those verified libraries. Also having vulnerability automation baked into your CI/CD pipeline will add an extra check for safety.
OK, the above is just general advice and by no means exhaustive. I could talk for hours on this subject, as it’s such a vast topic. Having worked across architecture, app development, and infrastructure, I strongly believe that security is a cross-cutting concern that should not be pushed onto a single team as their sole responsibility. It is something that everyone across the business should actively focus on.
That concludes today's article. Next week I'll talk about Risk Management, Liquidity Management and Safeguarding end users funds.