Most custody stories open with a photo of a safe. A steel box in a vault, a seed phrase laminated onto a card, two people holding two halves of a passphrase. It looks serious. It is mostly theatre. The threat to a private key is almost never a burglar with a drill. It is a compromised laptop, a malicious npm dependency, an insider with signing rights, and a backup that quietly copied the key somewhere you forgot to guard.
The real threat model
Begin by writing down who can move funds, and how. A raw private key has one property that makes it uniquely dangerous: whoever holds the full material can sign anything, forever, with no further checks. So every place the key has ever existed in one piece becomes part of your attack surface. The machine that generated it. The clipboard. The backup script. The engineer who ran the ceremony from a home network. Cold storage does not remove this problem. It relocates the single point of failure into a drawer and adds a slow, error-prone human step every time you actually need to sign.
HSMs, and why the key should never assemble
A hardware security module keeps the key inside tamper-resistant hardware and signs on request, so the material never leaves in the clear. That is a genuine improvement, but it is still one key in one box, and the box exposes an API that someone can be tricked into calling. Multi-party computation changes the shape of the problem instead of hardening the box. With MPC threshold signing, the key is never assembled at all. Independent parties each hold a share, and a signature is produced jointly without any party ever seeing the whole. There is no moment, and no machine, where the full key exists to be stolen. Compromising one share, or two, buys an attacker nothing on its own.
Policies, quorums, and ceremonies
Threshold signing gives you a natural place to encode rules. A two-of-three or three-of-five quorum is only the floor. The interesting part is what each signer verifies before it contributes its share: destination allowlists, per-transaction and daily limits, time locks on large transfers, a second human approval above a threshold. The signing layer becomes a policy engine, and the policy is enforced by cryptography rather than by hope that everyone followed the runbook. This is the line that matters most in the architecture. The application is only ever permitted to request a signature. It never holds key material. It asks, and the quorum decides.
Keys are born in a ceremony, and a good ceremony is scripted, recorded, and reproducible: known hardware, isolated machines, named participants, and a signed transcript of exactly what took place. Rotation deserves the same rigour as generation. Shares should be refreshable on a schedule and immediately after any staff change, using proactive resharing that mints new shares for the same address without ever reconstructing the key. Every request, approval, and rotation lands in an append-only log. That log is the whole difference between custody you can audit and custody you can only assert.
A spreadsheet of secrets tells you where the keys are. A signing log tells an auditor what authority was exercised, by whom, and under which policy. Only one of those survives a bad day.— Protocore · Blockchain engineering
The goal was never to make keys harder to reach. It is to make the raw key irrelevant. When no single machine ever holds the whole secret, when every movement of funds passes through a quorum and an explicit policy, and when the entire system emits a log a reviewer can read line by line, custody stops being an act of faith. You are no longer guarding a box and hoping. You are running a process you can show, test, and defend.
Have a system to build?
Tell us the problem. We'll come back with an architecture and a plan.
Start a project