The crypto industry is normally well ahead of its game when it comes to pure innovation and functionality, but security is a different matter. For years, custody risk in crypto was defined by a single fear: the theft of private keys. The industry responded by hardening storage with cold storage, air-gapped systems, MPC and other methods. It then recognized that protecting only the keys is not enough, introducing transaction security and policies to prevent malicious transactions that steal funds, although the keys remain safe. Both of these remain a serious threat, but focusing solely on private keys obscures a deeper shift: custody itself has expanded far beyond private keys.
“Custody” once meant safeguarding private keys. That definition no longer reflects reality. Custody has evolved into a complex, automated system that operates different kinds of transactions, across multiple venues, custodians, vendors, and internal systems. Modern trading firms operate across exchanges, staking platforms, liquidity venues, and infrastructure providers, each powered by API keys, validator keys, deployment credentials, and system-level secrets that can move capital directly or indirectly.
Many of these credentials are stored in secrets managers that, by design, return the full key to any authenticated process. Convenient, yes, but structurally fragile. If the execution environment is compromised, either by an external attacker, an employee that was threatened or a malicious dependency, the full key is compromised. Custody risk has expanded beyond dormant on-chain keys into a live execution layer, where capital moves in milliseconds and exposure happens in real time.
Custody security evolved in stages. First, the industry secured private keys in storage. It then moved beyond storage, embedding policy and multi-party controls to govern how those keys were used in execution. The next step is inevitable: apply the same zero-exposure and policy-driven discipline to every key and credential. In modern crypto operations, API keys, deployment credentials, and execution secrets carry significant risk. Extending private key best practices across this broader surface is no longer optional; it is the defining challenge of execution risk.
In recent years, the execution risk has emerged as the single-biggest vector for large-scale exploits. Cybercriminals are bypassing on-chain security mechanisms in favor of the soft underbelly, namely the API keys, server credentials and other off-chain secrets needed to facilitate trading, code deployment, staking and custodial actions. Recent major breaches, including the Bybit hack, started with an off-chain hack and compromised credentials, that later on led to on-chain loss of funds.
How big is the execution risk?
It’s big and structural. Asset managers, and trading firms, custodians and payment companies connect to dozens of CEXs, DEXs, liquidity providers and other vendors simultaneously. Each integration introduces its own credentials, access controls, and operational dependencies. Managing these spans across development, ops, trading, risk and security teams, which creates complexity that compounds over time.
Securing these operations is a never-ending struggle. Maintaining consistent security policies and multi-vendor access is a massive headache that’s largely manual, resulting in inevitable security gaps and configuration drift.
Execution risk is not inherent to automation, it is a byproduct of how trading systems have historically been designed. In many centralized exchange environments, API keys and operational credentials are placed directly inside trading infrastructure to eliminate latency. For market makers and trading firms, speed is not a feature, it is the business model. Even marginal delay affects revenue.
Over time, full-key availability inside live systems became normalized as the simplest way to achieve high-performance execution. Credentials sit in a constant state of readiness so transactions can be authorized instantly. The issue is not that capital moves quickly. It is that unilateral authority is embedded inside operational infrastructure. And when authority is concentrated where execution happens, it becomes the most predictable attack vector.
Existing controls fall short
Existing tools fall far short of what’s required, considering the complexity of modern execution environments.
While crypto exchanges, custodians and over-the-counter trading desks certainly employ robust security policies for specific operations, it’s incredibly difficult for them to synchronize those controls across such a fragmented ecosystem. In fact, it’s almost impossible to maintain consistent governance across 40-odd exchanges for any length of time. Since it’s done manually, in silo, errors are inevitable, and a single mistake can put millions of dollars in value at risk.
There’s also the counterparty risk to consider. Exchanges and custodians may have their own vulnerabilities in the shape of bugs, misconfigured infrastructure and inconsistent policy enforcement mechanisms. If a trading firm’s internal security code requires geofencing, but one of the exchanges it’s connected to has a buggy implementation of that control, it creates a risk at the point of execution.
The risk is intolerable
The lesson the industry learned from private key security is clear: eliminate full key exposure and enforce strict policy controls around usage. Those principles must now extend beyond on-chain private keys to every credential capable of authorizing value movement.
The solution is not simply better secret storage. Secret managers were built for convenience; they return the full key to any authenticated process. In live execution environments, that model distributes authority to multiple components of the system at the very moment capital is in motion.
What is required is zero key exposure architected systems where no single machine or employee ever holds unilateral control, combined with enforceable, context-aware policies governing how credentials are used. Multi-party computation (MPC) is one way to implement this model, but the principle is broader: expand private-key security best practices across the entire crypto execution layer.
