MPC Custody and Transaction Control

Provide custody and controlled execution of digital-asset transactions by distributing key shares across a set of signers that jointly produce a valid signature without ever reconstructing the private key. The pattern eliminates single points of key compromise and enforces policy-based approvals before any signature is released.

• Threshold signature scheme such as threshold ECDSA or threshold EdDSA; an m-of-n quorum produces a signature indistinguishable from a single-key signature.
• Signing nodes run inside hardened environments (trusted execution environments or hardware security modules) and hold one key share each.
• Policy engine validates each signing request against transaction limits, destination allowlists, and role-based approvals before releasing the signing request to the nodes.
• Orchestration API exposes request submission, approval workflow, audit events, and status queries to client applications.
• Key-generation ceremony creates the shares without ever materializing the full key; proactive key refresh rotates shares while keeping the public key stable.
• Audit log records signing attempts, approvals, denials, and share-refresh events for compliance review.
• Target chain (L1 or L2) that ultimately receives the signed transaction.

Guarantees:

• Key privacy: the private key is never reconstructed at a single location.
• Access control: a signature is released only when the quorum approves and the policy evaluates to true.
• Auditability: an end-to-end operations trail records approvals, denials, and signing events.
• Signature validity: if the quorum threshold is met, the resulting signature is verifiable by any chain that accepts the underlying scheme.

Threat model:

• Quorum compromise: if m nodes collude, the key is compromised; choose m and n accordingly and isolate nodes across operational domains.
• Policy-engine trust: a compromised or misconfigured policy engine can release signatures that violate the intended rules; combine with offline approvals for high-value flows.
• Operator censorship: a malicious or unresponsive operator can refuse to co-sign and freeze assets; an L1 exit path is required to mitigate this.
• Side channels: nodes that run in shared hardware or leaky TEEs can leak share material; rotate shares proactively and use attested enclaves.
• Out of scope: transaction-graph privacy and on-chain metadata protection. Signed transactions carry their usual public footprint.

• Performance: threshold signing adds latency relative to a single HSM; interactive protocols require several network rounds among the signing nodes.
• Cost: distributed infrastructure and continuous monitoring cost more than a single HSM deployment.
• Failure modes: if fewer than m nodes are reachable, no signature can be produced; geographic and operational diversity trade availability against quorum safety.
• Vendor trust: many production deployments rely on a vendor's signing protocol, policy engine, and attested hardware; open-source alternatives exist but often lack equivalent operational tooling.
• Operator censorship remains the core residual risk: without a forced exit path the custody operator can refuse to co-sign and freeze assets.

A bank issues a tokenized bond on Ethereum under a 2-of-3 custody policy across compliance, operations, and treasury.

• The operations desk initiates a transfer through the orchestration API.
• The policy engine checks the destination allowlist and the transaction limit, then notifies compliance for approval.
• Compliance approves via the dashboard; the two signing nodes run the threshold-signing protocol and emit a combined signature.
• The signed transaction is broadcast; bond tokens move to the investor address.
• The audit log records the approval path, the quorum members that signed, and the resulting transaction hash.