State of the Art of Private Key Security in Blockchain Ops - 1. Concepts,
Types of Wallets and Signing Strategies

Introduction

Welcome to the first in a series of posts about Blockchain Operations, the custody of crypto assets, and the management of private keys, which every blockchain-related project requires. This series is aimed at developers, security professionals, and organizations managing digital assets, providing insights into best practices and architectural considerations. Recently, we have been reminded how critical this topic is, as Bybit suffered the largest cryptocurrency theft to date, with more than $1.4 billion in assets stolen within seconds. However, this is not new and is not the last time it will happen; just a month after, Zoth's private key allowed to steal $8.4 million, and this is just another example; private keys have been stolen multiple times, organizations have mistakenly sent funds to incorrect addresses, and vulnerabilities in different platforms have resulted in the cumulative theft of more than $5 billion in recent years. This figure includes both centralized platform breaches and DeFi exploits, reflecting the widespread risks across different blockchain ecosystems. This figure does not even account for the numerous minor DeFi attacks that target everyday users through scams or sandwich attacks.

In this series, we will review the different types of custodial and signing strategies, the typical architectural elements involved in custodial solutions, and some common custody architectures. We have divided this series into four separate posts:

• [1/4]: Concepts, Types of Wallets and Signing Strategies (this post!)
• [2/4]: Common Custody Solutions Architectures
• [3/4]: Private Key Storage and Signing Module
• [4/4]: Approvals and Policies

In this first post, we will introduce the core concepts, including types of custodial solutions, wallet types, signing strategies, and the common storage locations for private keys.

When a project needs to interact with a blockchain, it must make several decisions on how to manage the private keys required for signing operations.

Custodial vs Non-Custodial

One of the first decisions for an organization is whether to use a custodial or a non-custodial solution.

• Custodial Solutions: In this case, a third party manages and stores your private keys. The risk is shifted to the third party rather than relying on your own resources.
• Non-Custodial Solutions: The organization itself is responsible for storing and managing access to its private keys.
• Hybrid Solutions. Many third-party services that provide digital asset custody offer a hybrid approach. In these setups, most of the infrastructure is managed by the third party, but the private keys are stored by the organization (e.g., in HSMs). This offers benefits to organizations that do not want to handle blockchain interactions but still want control over their private keys. It is crucial to understand whether the third party, even without storing the private keys, has enough permissions to use the organization's keys to sign arbitrary transactions.

Hot Wallets, Cold Wallets

When discussing custody, the terms "hot wallet" and "cold wallet" are commonly used to distinguish wallets used for daily operations from those that store larger funds requiring stricter security policies. The primary difference lies in the level of protection that can be applied to each of them.

• Hot Wallets: These wallets are used for daily operations and are often accessible by automated processes. Because they must be used continuously (often triggered automatically by other processes) they are more susceptible to compromise. Consequently, they require different security measures than private keys that are not needed as frequently.
• Cold Wallets: These wallets do not require frequent use and can be kept offline. When used for custody, cold wallets typically store larger funds that are not needed for daily operations (such as withdrawals). Depending on the organization’s policies and the expected usage frequency, air-gapping may be applied, where the system remains physically disconnected from any network, requiring manual intervention to connect before use.

The term "warm wallets" is sometimes used to refer to a concept similar to cold wallets but with more frequent usage requirements. The specific implementation varies, depending on the restrictions and policies in place. Examples may include keys that remain connected but have more restrictive approval policies requiring manual intervention.

Operational Keys

The distinction between hot and cold wallets is clear in custody, but what about keys that do not directly hold crypto assets but instead operate smart contracts (e.g., a DeFi protocol)? These are referred to as Operational Keys.

I tend to think on operational keys like access badges in a company building; some let you into the lobby, while others open the server room. If everyone had master access, the entire system would be at risk.

The use of these keys depends on the business logic within smart contracts and the authorization mechanisms implemented.

It is advisable to establish roles in smart contracts not only based on logical functionality but also according to the risk and frequency of execution. The more granular these roles are, the easier it is to aggregate some into separate private keys.

The hot and cold wallet analogy can still apply to operational keys based on usage frequency. For instance, many smart contracts have functionality that allows contract upgrades. The key used for upgrading a contract’s implementation is considered highly sensitive. Since contract upgrades are rarely needed (possibly only in emergencies or for periodic functionality updates), the protection measures for these keys should be comparable to those required for cold wallets.

On the other side, some operations, such as automatically adding external information to a contract, might have minimal risk and require frequent execution. These operational keys would need protections similar to hot wallets.

Signature Authorization Mechanisms

Operations that involve blockchain transactions may require multiple valid signatures. It is common, and highly recommended, to require multiple signatures for critical operations (such as upgrading smart contracts).

You can think of multisig like what you've seen in films about nuclear launch protocols; multiple officers must turn their keys simultaneously, each stationed at different locations. This prevents any single individual from acting alone, which is precisely the kind of protection needed for sensitive blockchain operations like contract upgrades or large fund movements.

Depending on the blockchain network and system, multi-signature functionality can be implemented in several ways:

On-Chain Multisig

• Multisig natively supported by the Blockchain Network (e.g. Bitcoin): This approach is implemented within the blockchain itself, which means organizations using multisig do not need to worry about incorrect implementations. However, a downside is that natively supported multisig often requires multiple transactions to be broadcasted, increasing costs and potentially leaking the intent of the transaction with the first signature.
• Multisig implemented in smart contracts (e.g. Ethereum): Ethereum does not support multisig at the protocol level, but this functionality can be implemented using smart contracts. To verify signatures, authentication can rely on the network’s built-in verification or structured message signing (e.g., EIP-712). When implementing this functionality via a smart contract, a thorough audit is critical, as vulnerabilities could allow attackers to bypass authentication. A widely known example of a smart contract-based multisig wallet is Gnosis Safe, now Safe{Wallet}. This solution recently made headlines in the largest cryptocurrency theft ever recorded (to date). While smart contract wallets offer flexibility, it is important to limit the attack surface, as increased functionality introduces more potential vulnerabilities.

Off-Chain Signing Mechanisms

• Approval Policies in Custom Off-Chain mechanisms: Off-chain components may create approval policies based on permissions, private keys or other mechanisms, that grant the ability to sign a transaction. Approval policies is a common element in custody solutions that can be also used as an addition to other multisig mechanisms. In general, this is considered a less secure approach than other multisig methods from a design perspective, as there is at least a single point of compromise in the module that has access to the private key and signs the message.
• MPC (Multi-Party Computation): MPC is a cryptographic technique that enables multiple parties to compute a valid signature while keeping their inputs private from each other. This technique is used by platforms like Fireblocks or MPCH. While this being performed off-chain, the private key is never created or stored in a single location, and is blockchain-agnostic. Only a subset of shares is required (M of N) and shares can be rotated or updated without affecting the original key, adding some flexibility.

Signature Authorization Mechanisms Comparison

The table below summarizes the signing strategies considered in this post, with pros and cons

As it can be seen, the strengths and weaknesses of the different signature authorization mechanisms could be complemented to add the flexibility of off-chain mechanisms to the security of on-chain enforced mechanisms, allowing to complement human reviews with automated processes reviewing information that may not available directly on-chain.

Final Thoughts

Choosing the right key management strategy is one of the most important decisions for any blockchain-related project. It is also important to notice that, in many cases, where a third party is used to custody your private keys, the API keys that you need to manage hold a similar power to a private key, and the same security measures need to be applied to protect those API keys. In the next post, we will explore the core elements involved in custodial solutions, such as signing modules, approval policies, settlement and storage.