Architecting Institutional MPC Custody: Threshold Signatures Beyond the Hype

By Steven Geller, Founder — Trust Boundary Systems Inc. · August 5, 2026

Institutional digital asset custody is, at its core, a key management problem wrapped in a governance problem. Every architectural decision — signature scheme, shard topology, approval workflow, recovery path — either shrinks or enlarges the set of people, machines, and failure modes that can move funds. This article walks through how we think about MPC custody design for institutions, based on patterns that hold up in production rather than in vendor decks.

Why Single Keys and Naive Multisig Fail Institutions

A single private key is a single point of catastrophic failure: whoever holds it can move everything, and losing it means losing everything. Hardware wallets and HSMs harden the storage, but they do not solve the governance problem — an institution cannot let one device, or one administrator of one device, be the trust root for nine figures of client assets.

On-chain multisig looks like the obvious answer, and for treasuries it often is. But naive multisig breaks down at institutional scale for several reasons. Every signer and every threshold change is visible on-chain, leaking your security posture to anyone watching. Each supported chain needs its own multisig contract or script, multiplying audit surface. Quorum changes require on-chain transactions, which is operationally slow when an employee departs. And smart contract multisigs inherit contract risk — the history of the space includes multisig wallet bugs that froze or drained funds at scale.

Threshold Signatures vs On-Chain Multisig

Threshold signature schemes (TSS) move the quorum mathematics off-chain. A key is generated in shards via distributed key generation (DKG), and any t-of-n subset of shard holders can collaboratively produce a single, ordinary signature — indistinguishable on-chain from a single-key signature. The trade-offs versus on-chain multisig:

• Chain agnosticism. One TSS stack can sign for ECDSA and EdDSA chains; no per-chain contract logic to audit and maintain.
• Privacy. The signing policy is invisible on-chain. Observers see a normal address, not your quorum structure.
• Off-chain policy enforcement. Approval rules, velocity limits, and address allowlists live in your policy engine, not in contract code, so they can evolve without on-chain migrations.
• The cost. The cryptographic protocols (GG20, CGGMP21, FROST for Schnorr-style signatures) are subtle. Security lives in protocol proofs, implementation correctness, and the MPC node software — an audit burden you take on yourself rather than delegating to battle-tested contract code.

In practice, mature institutions run both: TSS for operational wallets where flexibility matters, on-chain multisig or smart accounts where on-chain verifiability is a feature (treasury transparency, DAO holdings). The mistake is treating it as a religious war instead of a placement decision.

Key Ceremony and Shard Governance

The key ceremony is where most custody architectures quietly succeed or fail. DKG must run on infrastructure you control, with attested code, recorded proceedings, and no single operator ever seeing more than their own shard. Design rules that hold up:

• Quorum design. A 2-of-3 is operationally comfortable but concentrates risk; 3-of-5 or 4-of-7 better matches institutional separation-of-duties norms. Choose t so that no plausible collusion subset — two employees, or one vendor plus one insider — reaches the threshold.
• Organizational separation. Shards should map to distinct legal and organizational entities: the operator, an independent trustee, a recovery provider. Geographic separation matters too — a region-level outage must not take out your quorum.
• HSM-backed shards. Each shard lives inside an HSM or hardened enclave with its own access controls, so extracting a shard requires breaking hardware, not just reading a file. Pair this with strict operator authentication: ceremony participation should require multi-person physical or cryptographic presence.

Hot, Warm, Cold: Tiering by Velocity, Not Fear

Tiering is an economic decision: how much value sits behind each latency of access. A workable default for institutions is a hot tier holding hours of expected outflow behind automated policy checks, a warm tier holding days of float behind human dual-control approvals, and a cold tier holding the remainder behind ceremony-gated, quorum-heavy key usage with time delays. The key discipline is that promotion of funds between tiers is itself a governed, logged, policy-checked operation — not an ad-hoc operational habit. Rebalancing triggers should come from measured flow data, reviewed quarterly.

Policy Engines and Dual Control

The policy engine is the actual product. Signing is the easy part; deciding whether a signature should happen is where institutions earn their license to operate. A production-grade engine evaluates every request against address allowlists (with time-locked addition of new destinations), per-transaction and cumulative velocity limits, role-based initiation and approval (four-eyes minimum on anything above the automated threshold), and anomaly signals from your monitoring stack. Critically, policy evaluation must be deterministic and reproducible: given the same request and the same policy version, every quorum node must reach the same approve/deny decision, and the decision record must be part of the audit trail.

Disaster Recovery and Shard Rotation

Recovery design starts from a hard truth: you cannot back up an MPC key by copying shards to a safe — that recreates the single-key problem with extra steps. Instead, plan for shard-level recovery. If one shard is lost or its holder exits, the remaining quorum performs a proactive resharing (refresh) to a new n-set, rendering the old shard worthless. Rotation should also run on a schedule, not only on incidents: periodic proactive refresh limits the value of slowly accumulated compromise. Full catastrophic recovery — quorum unrecoverable — requires a separately governed recovery key or escrow arrangement, which must be tested on a calendar, in tabletop exercises, with the same seriousness as a financial audit. Untested recovery is not recovery.

Proof-of-Reserves and Auditability

Regulated products — spot crypto ETFs being the canonical case — demand continuous, verifiable answers to "are the assets there and are they segregated?" MPC custody supports this well: on-chain addresses are publicly observable, and the custodian can periodically sign attestations from reserve addresses to prove control without moving funds. The harder engineering is the liability side and reconciliation: your internal ledger, the on-chain state, and the fund administrator's books must reconcile on a fixed cadence with cryptographic evidence. Design the attestation pipeline — address registries, signed balance snapshots, auditor-facing verification tooling — from day one, because retrofitting auditability into a custody stack is painful.

Operational Pitfalls We See in Production

In production we have seen the same failure modes recur: ceremony procedures documented but never rehearsed end-to-end; quorum topologies where two shards secretly live in the same cloud region or under the same admin credentials; policy engines with manual override paths that become the default path under operational pressure; and monitoring that watches node uptime but not signing-latency anomalies or unusual approval patterns. The technology is rarely what fails. The operating discipline around it is.