Splitting the key does not decide whether to sign

MPC solves an important problem well: no single party ever holds a complete key. The question of what the assembled parties are signing is a different problem, and MPC answers it by assumption.

Part of Digital asset custody

What MPC provides

A threshold signature scheme distributes key material so that a complete private key never exists in one location. Signing requires a threshold of parties to participate in a protocol, and no participant learns the others' shares.

The first four rows are real and substantial. The fifth is the subject of this piece.

Where the transaction comes from

An MPC signing ceremony begins with a message to be signed. That message is constructed and supplied by an initiating system — a treasury application, an orchestration service, a policy engine.

# The initiating system decides what gets signed

tx = build_withdrawal(destination, amount, asset)

# MPC parties participate in signing THIS message.
# Each party's role is protocol participation, not review.

signature = mpc_sign(tx, threshold=3, parties=5)

# If build_withdrawal was influenced by an attacker,
# five honest parties produce a valid signature over
# a transaction nobody wanted.

This is not a defect in the scheme. MPC is a signing protocol and signing protocols sign what they are given. The assumption is that something upstream decided correctly.

The human-participation variant

Some deployments have human operators approve before their node participates. This is better and it inherits the display problem exactly as multisignature schemes do.

• What the operator sees comes from an interface, not necessarily from the bytes being signed
• Operators approving routinely develop the same reflexive behaviour as any repeated approval
• The approval is typically recorded as application state, so there is no evidence of what was shown

So a human-in-the-loop MPC deployment has the same gap as a hardware multisignature setup: the signers were present and what they saw was not necessarily what executed.

Layering the two

Read top to bottom: the human decides, the policy constrains, the key scheme signs. Each layer addresses a threat the others do not, and removing any one leaves a gap.

The practical integration

# Before the MPC ceremony begins

statement = render_from_bytes(tx)          # decoded, complete
receipt   = await_human_signature(statement)
verify(receipt, issuer_jwks) or abort()
require(receipt.digest == sha256(JCS(render_from_bytes(tx))))

# Only now does the ceremony start
signature = mpc_sign(tx, threshold=3, parties=5)

# The receipt is retained with the transaction record.

The recomputation on the fourth line is what makes it robust. The statement is derived from the transaction bytes both at approval and immediately before signing, and a difference halts the ceremony.

What to ask an MPC vendor

1. Where does the message to be signed come from, and what would happen if that system were compromised?
2. Do your operators review the transaction, and if so is what they see derived from the bytes being signed?
3. Is there a record of what each operator was shown, or only that they approved?
4. Can the ceremony be gated on an external approval your platform cannot itself produce?

The third question tends to produce the most informative answer. Most platforms record approval as a status; very few record the rendered content.

None of this diminishes MPC. It is the right answer to key custody and the largest custody incidents of recent years did not involve key compromise — which is precisely the argument for attending to the layer above it.

A worked example: a compromised orchestrator

The layers compose rather than compete: MPC removes the single point of key compromise, and a human signature over the rendered effect removes the question of whether anyone meant it.

Objections and honest limits

“Our MPC has a human-participation mode.” Worth checking what the human is shown. If it is a dashboard fed by the same orchestrator, a compromised orchestrator controls both the transaction and the rendering.

“This adds latency to every transaction.” Only to the ones you gate. Small, frequent transfers run under a bounded grant; the gate belongs on the irreversible, high-value tail.

Questions for an MPC vendor

1. Where does the transaction payload originate? That system is your real trust boundary.
2. What is the human shown, and who renders it? If the same system, it is not independent.
3. Is the approval signed or clicked? A click is a session event.
4. Can I verify approvals offline later? Without calling you.
5. What happens if your service is unavailable? Fail-open is the usual undocumented answer.

Terms used here

Multi-party computation

Producing a signature from key shares held by several parties, so no single party holds the key.

Rendered effect

What the transaction will actually do, shown to a person in terms they can judge.

Blind approval

Approving a payload whose effect was never rendered independently.

Frequently asked questions

Is MPC inadequate? It is the right answer to key custody and does that job well. It signs the message it is given, so what gets signed is decided upstream.

Does human approval in an MPC flow solve it? It helps and inherits the display problem. What the operator sees may not be derived from the bytes being signed, and the approval is usually recorded as a status.

Do MPC and seen-and-signed compete? No. They are layers: the human decides, the policy constrains, the threshold scheme signs. Removing any layer leaves a distinct gap.

What should be asked of a vendor? Whether there is a record of what each operator was shown, not merely that they approved. Very few platforms record rendered content.

Does MPC replace human approval? No. It removes a custody risk. Whether the transaction is the intended one is a separate question.

Can the two be layered? Yes, and they should be: a human signature over the rendered effect becomes a required input to the MPC signing policy.

Does this slow every transaction? Only the gated ones. Routine transfers run under a bounded grant.

Sources and further reading

• Published literature on threshold signature schemes and multi-party computation.
• FTC — business guidance on marketplaces and consumer protection
• Post-incident analyses of custody compromises involving display mismatch.
• NIST Multi-Party Threshold Cryptography project