Opinion by Ido Sofer, founder and CEO at Sodot.
Crypto led the world in financial innovation, but its security model has not kept pace. For years the industry defined custody risk narrowly: protect private keys from theft. Firms hardened storage with cold wallets, air-gapped systems and multi-party key schemes, then layered transaction policies and approvals. Those measures remain critical, but focusing only on on-chain keys misses a major evolution: custody now includes everything that moves capital at execution time.
Modern custody is an automated execution ecosystem. Trading desks, validators, staking operators, liquidity protocols, exchanges, custodians and internal systems all rely on API keys, validator keys, deployment credentials and system secrets. Many of those secrets live in “secret managers” that, for convenience, return the full credential to any authenticated process. That convenience creates structural fragility: when the execution environment is compromised—by an external attacker, a coerced or negligent employee, or a malicious dependency—the full key is exposed and funds can move in milliseconds. Custody risk has shifted from dormant, offline keys to a live execution layer where authority and exposure coincide.
How security evolved
Security progressed from secure key storage to policy controls and multi-party governance over key use. The next necessary step is to apply zero-exposure discipline and context-aware policy enforcement to every credential and secret. API keys, deployment credentials and execution secrets now carry material risk comparable to on-chain private keys. Extending the same operational and cryptographic safeguards used for private keys across this broader attack surface is no longer optional—it’s the central challenge of execution risk.
Why execution risk is a primary exploit vector
Attackers increasingly target off-chain weaknesses: compromised API keys, server credentials, CI/CD secrets and other off-chain artifacts used for trading, staking and deployments. High-profile incidents—such as the Bybit compromise—began with credential exposure off-chain and quickly led to on-chain losses. The structural reality is that firms integrate with dozens of external venues and vendors; each integration adds credentials, configurations and dependencies. Governance across that fragmented ecosystem is often manual and inconsistent, producing configuration drift and gaps that attackers exploit.
Why historical system design contributed
To minimize latency, many trading and market-making systems store full credentials inside live infrastructure. For high-frequency strategies, every millisecond matters, and returning the key to the executing process became the simplest path to performance. The problem isn’t fast execution itself; it’s concentrating unilateral authority at the point of execution. Where one machine or account can unilaterally move large amounts of capital, that machine becomes the most attractive attack target.
Why current controls fall short
Individual counterparties—exchanges, custodians, OTC desks—can enforce strong controls internally, but synchronizing those controls across partners and integrations is extremely hard. Siloed, manual policies create inevitable blind spots. A partner’s buggy geofencing, a poorly implemented API restriction or a stale configuration can nullify another firm’s protections. Secret managers that return full keys to processes distribute authority exactly when and where capital moves, amplifying the risk rather than containing it.
What must change
The industry must eliminate full-key exposure across the entire execution layer and enforce strict, contextual policies for every credential. Secret managers built for convenience should not be the default model for high-value execution secrets. Instead, architectures must ensure no single machine or employee can obtain unilateral control of a credential at the moment funds move.
Zero-key-exposure architectures provide that alternative. Under this approach, signing or authorization happens without ever revealing the full secret to a single host or process; policy checks—such as amount limits, destination restrictions, time and location constraints—are enforced before any action is approved. Multi-party computation (MPC) is one way to implement this pattern, but the principle is broader: apply private-key best practices—no single point of authority, enforceable policies, tamper-resistant decision flows—across API keys, deployment credentials and execution secrets.
Balancing speed and safety
Security and latency don’t have to be mutually exclusive. Designing zero-exposure, policy-driven systems with performance in mind allows firms to preserve trading speed while removing unilateral points of failure. That requires engineering investment and a shift in threat modeling: treat off-chain credentials with the same rigor as on-chain private keys and assume execution environments are attractive targets.
The path forward
Reducing execution risk means rethinking how credentials are stored, used and authorized. Firms should adopt architectures that never expose full keys to executing hosts, require multi-party or threshold authorization for high-value actions, and implement centralized policy enforcement that is verifiable across partners. Standardizing these practices across the ecosystem—exchanges, custodians, service providers and counterparties—will be critical to lowering systemic risk.
Opinion by Ido Sofer, founder and CEO at Sodot.
This piece reflects the author’s view and may not represent the views of the publisher. It has been edited for clarity. Readers should perform their own due diligence before acting on its recommendations.