I watched another hot wallet get drained recently, millions lost in minutes, and the first thing everyone wanted to talk about was the attack vector: a spoofed identity, a compromised account, social engineering that gave someone access to keys they should never have been near.
The attack was the trigger, and the failure happened much earlier. Who was watching the balance in that hot wallet, and had anyone recently asked whether it still matched operational need? Every exchange and custody operation keeps some value hot for liquidity, and that’s fine. The failure is when the hot balance drifts far beyond what daily operations require and the ratio stops getting reviewed. Once an account is compromised, the blast radius depends entirely on decisions made months or years earlier: how much was exposed, what controls were in place, whether anyone had stress-tested the separation between hot and cold.
Every crypto team I talk to can tell me where their keys live. Most of the growing-stage teams I’ve worked with, though, can’t tell me what happens when one of those keys needs to change in the middle of an incident, with money moving and the people who understand the system unreachable.
That gap between having keys and operating them is where most failures happen. The system around the keys was seldom designed to be exercised under stress, even when the cryptography itself is sound.
The gap between having keys and operating them is where most failures happen.
I’ve built both ends of this spectrum: enterprise custody systems where a single key ceremony took a full day, involving air-gapped machines, dual control, notarized witnesses, and a checklist that couldn’t be skipped; and crypto-native signing infrastructure where threshold cryptography keeps a live network signing blocks in real time.
These are different disciplines entirely, yet the industry keeps pretending they’re interchangeable.
What Signing Infrastructure Looks Like
The simplified version of this discussion starts with hot vs. cold wallets and ends with three boxes on a slide. That framing works for explaining concepts, but it’s not how you design something that signs transactions reliably in production.
In a real system, a transaction request never goes straight to a key. It first passes through policy: does this transaction fall within expected size and frequency? Does it match known behavior? Is the destination address new, flagged, or unexpected? Has the transaction been simulated against current chain state so you know what it will do, not what it claims to do?
Only after those checks does the request reach the signing layer, and this is where architecture choices start to matter.
In a traditional multisig, you’re coordinating independent signers, each holding a complete private key. The mental model is clear, which is why teams like it, and multisig has real advantages beyond simplicity: every approval is recorded on-chain, giving you a transparent audit trail that regulators and governance teams can verify independently. Years of battle-testing across implementations like Safe have made its failure modes well-understood. The downside is equally clear: every signer is a discrete failure domain.
In a threshold scheme like FROST (used by the Stacks signer network), there is no full private key anywhere. Each participant holds a share, and a coordinator runs a multi-round protocol to produce a single valid signature without ever reconstructing the key. The tradeoff goes both directions: threshold signing removes single-key compromise risk, but it introduces liveness requirements, opaque on-chain footprints, and implementation sensitivity that has bitten even major providers (the BitForge vulnerabilities showed that slight implementation mistakes in MPC protocols could let attackers extract private keys entirely). If enough signers go offline mid-ceremony, nothing degrades gracefully, and you simply don’t sign.
Many practitioners argue multisig remains the better choice for governance and long-term treasury, where transparency matters more than operational flexibility, whilst threshold schemes earn their complexity in high-frequency operational signing.
Monitoring is the piece most wallet discussions skip entirely. If signing is critical, it needs the same observability as any other production system: latency across signing rounds, signer participation rates, failure modes by node, alerting on abnormal transaction patterns like sudden value spikes, new destinations, or activity outside normal windows.
Two Disciplines That Rarely Talk to Each Other
In enterprise custody environments, provisioning a single HSM can take most of a day: air-gapped laptops, verified OS images, two authorized operators from different reporting chains, physical controls, audit logs written for the regulators who will eventually read them, and hardware designed to zeroize keys if someone so much as opens the casing.
Self-custody in crypto looks nothing like that. A hardware wallet generates a seed phrase at a kitchen table, the backup is twelve words on paper, and rotation amounts to moving funds if something feels wrong. Recovery, if we’re honest, is usually theoretical.
These are responses to entirely different threat models, built on different assumptions about who the adversary is and where trust lives.
Enterprise custody minimizes insider risk and operational mistakes, but adds counterparty and regulatory risk. Self-custody removes intermediaries entirely, but turns the owner into the security team, compliance team, and incident responder.
There’s a legitimate middle ground here: regulated hybrid custody, where a company and a qualified custodian share control, with insurance, compliance frameworks, and documented key ceremonies. That model exists for good reason, and teams using it intentionally are often in a better position than either extreme.
The danger is the accidental middle ground, which is where most growing crypto companies operate: too large for individual-grade tooling, not structured enough for real enterprise custody, and without the intentional design of a proper hybrid model. You see treasury systems built on consumer wallets, multisigs where one founder controls multiple keys, cold storage that amounts to a hardware wallet in a desk drawer, and key rotation permanently stuck on the roadmap.
These setups rarely fail in dramatic ways; they fail quietly. A cosigner leaves and the access list doesn’t get updated, firmware drifts out of date, recovery instructions live in someone’s head, and the one person who understands the process goes on vacation, or worse, leaves entirely. Basic operational hygiene that never got prioritized until it was too late.
Keys Are Production Infrastructure
Most of the industry treats key management like setup work: generate keys, store them safely, move on. In practice, keys behave like production infrastructure, requiring procedures, ownership, testing, and change management.
Take key generation. In environments where the value at risk is meaningful, generation happens on machines that never touch a network, using known-good images, in controlled rooms, with witnesses and documented custody of backups. That’s not paranoia; it’s what happens when people expect to be held accountable later. Compare that to initializing a hardware wallet in a public place and hoping the environment was clean. The gap is purely operational.
Rotation is where things usually fall apart. Rotating a secret in traditional infrastructure is annoying but routine, whilst rotating a crypto key means moving assets on-chain, paying fees, coordinating timing, and updating every downstream system that references the address. So teams delay it, then forget it, then normalize the delay.
Every day a key isn’t rotated, its attack surface grows as new software touches it, new people learn where it lives, and old assumptions age out.
Offboarding is worse. In threshold schemes, you can reshuffle shares without changing the public key, but in standard multisig, replacing a signer means creating a new address and migrating funds. That’s painful when everyone cooperates, and much harder when someone doesn’t, or can’t.
Recovery is where the gap between planning and reality becomes most painful. I’ve watched teams discover mid-incident that their recovery plan had never been tested: the backup was stored in a closed bank branch, the passphrase lived in a password manager tied to a compromised laptop, and the script to reassemble the multisig hadn’t run in years and depended on libraries that no longer existed.
So I ask one question now: when was the last time you performed a recovery? I don’t mean reviewing the doc or nodding at the diagram. I mean restoring from backup, producing a valid signature, and verifying the full path worked.
If the answer is “never,” everything else is aspirational.
When Did You Last Test It?
Sound cryptography is necessary but insufficient. The harder discipline is treating signing the way serious teams treat production systems: with runbooks, rotation schedules, incident drills, and clear ownership when something goes wrong.
That drained hot wallet I started with? The cryptography was fine, the keys were generated correctly, the multisig was configured properly. What failed was everything around the keys: the balance review that stopped happening, the access controls that drifted, the assumption that a compromised account was someone else’s problem.
The industry will start to feel different when “we have a cold wallet” gets the same follow-up as “we have backups” does in any credible engineering org: when did you last test it? Using multisig and operating signing infrastructure are as different as owning a lock and running security. Most teams aren’t ready to answer that question yet, and every unrotated key is an assumption that the world around it hasn’t changed.