H33-MPC: Post-Quantum Threshold Signing

Parameter	Value
Operations	Sign, KeyGen, Reshare
Threshold	Configurable N-of-M
Attestation	Dilithium (ML-DSA, NIST PQC)
Session storage	In-memory DashMap (zero persistence)
Party contributions	Zeroize-on-drop (memory-safe)
Sign gateway	gRPC proxy to MPC backend
Max rounds (Sign)	2 (FROST protocol)
Max rounds (KeyGen)	3 (DKG protocol)
Max rounds (Reshare)	2
Post-quantum	ML-DSA-5 attestation (NIST Level 5)

API

MPC Session API

Four endpoints for the complete MPC lifecycle. Create, contribute, finalize, and query session status. All endpoints authenticated via API key.

MPC Session — 8 credits/session

Full multi-party computation session including creation, all party contributions, threshold finalization, and ML-DSA attestation of the result.

POST/v1/mpc/session/create

POST/v1/mpc/session/{id}/contribute

POST/v1/mpc/session/{id}/finalize

GET/v1/mpc/session/{id}/status

Step 1 — Create a 2-of-3 signing session

curl -X POST https://api.h33.ai/v1/mpc/session/create \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "operation": "Sign",
    "threshold": 2,
    "total_parties": 3,
    "party_ids": ["party_alice", "party_bob", "party_carol"],
    "message_hash": "base64_sha256_of_message..."
  }'

# Response:
# {
#   "session_id": "mpc_abc123",
#   "phase": "AwaitingContributions",
#   "contributions_needed": 2,
#   "max_rounds": 2
# }

Step 2 — Party Alice contributes her key share

curl -X POST https://api.h33.ai/v1/mpc/session/mpc_abc123/contribute \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "party_id": "party_alice",
    "round": 1,
    "payload": "base64_key_share_alice..."
  }'

# Response: { "accepted": true, "contributions_so_far": 1, "threshold": 2 }

Step 3 — Party Bob contributes (threshold met)

curl -X POST https://api.h33.ai/v1/mpc/session/mpc_abc123/contribute \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "party_id": "party_bob",
    "round": 1,
    "payload": "base64_key_share_bob..."
  }'

# Response: { "accepted": true, "contributions_so_far": 2, "phase": "ReadyToFinalize" }

Step 4 — Finalize session (ML-DSA-attested result)

curl -X POST https://api.h33.ai/v1/mpc/session/mpc_abc123/finalize \
  -H "Authorization: Bearer $H33_API_KEY"

# Response:
# {
#   "phase": "Finalized",
#   "result": "base64_threshold_signature...",
#   "attestation": {
#     "algorithm": "ML-DSA-5",
#   "signature": "base64_dilithium_sig...",
#     "session_id": "mpc_abc123",
#     "parties": ["party_alice", "party_bob"],
#     "threshold": "2-of-3"
#   },
#   "contributions_zeroed": true
# }

Distributed Key Generation — 3-of-5 setup

curl -X POST https://api.h33.ai/v1/mpc/session/create \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "operation": "KeyGen",
    "threshold": 3,
    "total_parties": 5,
    "party_ids": ["custodian_1", "custodian_2", "custodian_3", "custodian_4", "custodian_5"]
  }'

# DKG requires 3 rounds of contributions from all parties.
# Each party submits per-round payloads:
#   Round 1: Commitment polynomial
#   Round 2: Share distribution
#   Round 3: Verification
#
# After all 3 rounds, finalize produces:
# {
#   "phase": "Finalized",
#   "result": "base64_public_key...",
#   "attestation": { "algorithm": "ML-DSA-5", ... },
#   "key_shares_distributed": true,
#   "contributions_zeroed": true
# }

Key Reshare — rotate from 2-of-3 to 3-of-5

curl -X POST https://api.h33.ai/v1/mpc/session/create \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "operation": "Reshare",
    "threshold": 3,
    "total_parties": 5,
    "party_ids": ["new_custodian_1", "new_custodian_2", "new_custodian_3",
                  "new_custodian_4", "new_custodian_5"]
  }'

# Reshare requires 2 rounds. Existing shareholders contribute
# current shares, and the protocol generates new shares for
# the updated party set. The full key is NEVER reconstructed.
#
# After finalization:
# - New shares distributed to 5 custodians
# - Old 2-of-3 shares are cryptographically useless
# - New threshold: 3-of-5
# - Zero downtime during rotation
# - ML-DSA attestation on reshare event

Feature	H33-MPC	Fireblocks	Lit Protocol	Threshold Network
Threshold scheme	Configurable N-of-M	2-of-3 (fixed)	N-of-N (all required)	N-of-M
PQ attestation	ML-DSA-5 (L5)	None	None	None
Session model	Stateless (DashMap)	Persistent (HSM)	Blockchain-anchored	On-chain (Ethereum)
Key material safety	Zeroize-on-drop	HSM-stored	Encrypted at rest	On-chain
Operations	Sign, KeyGen, Reshare	Sign only	Sign, Encrypt	Sign
Integration	REST API (4 endpoints)	Proprietary SDK	Lit JS SDK	Ethereum contracts
Self-hosted	Yes	No (SaaS only)	Partial (nodes)	No (Ethereum)
Audit trail	PQ-signed attestation	Proprietary logs	On-chain events	On-chain events
Pricing	8 credits/session	Enterprise pricing	Token-gated	Gas fees

Frequently Asked Questions

What does threshold signing mean?

Threshold signing splits a single signing key into multiple shares distributed across separate parties. A valid signature can only be produced when a minimum number of parties (the threshold) contribute their shares. For example, in a 2-of-3 setup, any 2 of the 3 key holders can produce a valid signature, but no single party can sign alone. The full key is never reconstructed in one place.

How many parties can participate in an MPC session?

H33-MPC supports configurable N-of-M thresholds where M (total parties) can range from 2 to 256. The threshold N can be any value from 1 to M. Common configurations are 2-of-3, 3-of-5, and 5-of-7. Larger party counts are supported for enterprise governance scenarios such as board approvals or multi-jurisdiction regulatory requirements.

What happens if one party goes offline during a session?

That is exactly what threshold signing is designed for. If you have a 2-of-3 configuration and one party is offline, the remaining two parties can still produce a valid signature. The session moves to the finalize phase once the threshold number of contributions is received. If the threshold cannot be met (for example, 2 of 3 parties are offline in a 2-of-3 scheme), the session remains in AwaitingContributions until enough parties respond or the session times out.

What is the latency per signing round?

A complete MPC session (create, contribute, finalize with ML-DSA attestation) typically completes in under 50 milliseconds for local network scenarios. The dominant cost is the ML-DSA sign-and-verify in the finalize phase (~191 microseconds). Network round-trip time between parties is usually the bottleneck. For co-located parties, total latency is in the low single-digit milliseconds.

How is H33-MPC different from regular multi-sig?

Traditional multi-sig requires multiple independent signatures that are verified separately on-chain. Each signer's public key is visible. MPC threshold signing produces a single standard signature that is indistinguishable from a regular single-party signature. The verifier does not know (and cannot determine) that multiple parties were involved. This provides better privacy, lower on-chain gas costs, and compatibility with any signature verification system.

What are the 4 phases of an MPC session?

Phase 1 (Create): Define the operation (Sign, KeyGen, or Reshare), set the N-of-M threshold, and register party IDs. Phase 2 (Contribute): Each party submits their key share or signature fragment, validated and stored with Zeroize-on-drop memory safety. Phase 3 (Finalize): Once threshold is met, shares are combined via SHA3 hash (KeyGen/Reshare) or gRPC gateway (Sign). Phase 4 (Attested): The result is signed with Dilithium ML-DSA and all party contributions are zeroed from memory.

Can H33-MPC work with existing wallet infrastructure?

Yes. Because MPC threshold signing produces a standard signature, the output is compatible with any wallet or verification system that accepts the target signature scheme. For blockchain wallets, the MPC-signed transaction is indistinguishable from a single-signer transaction. This means you can upgrade existing single-key wallets to threshold custody without changing the on-chain contract or verification logic.

How does key resharing work for adding or removing parties?

The Reshare operation redistributes key shares to a new set of parties without ever reconstructing the full signing key. You create a reshare session specifying the new party set and new threshold. The existing shareholders contribute their current shares, and the protocol generates new shares for the updated group. Old shares become cryptographically useless after resharing. This enables adding new team members, removing departing ones, or changing the threshold, all with zero downtime.

Is H33-MPC compatible with Ethereum and Solana?

Yes. H33-MPC can produce threshold ECDSA signatures (for Ethereum and EVM chains) and threshold Ed25519 signatures (for Solana). The output is a standard signature that passes on-chain verification. The ML-DSA attestation is an additional post-quantum proof layer that travels alongside the transaction as metadata. It does not affect on-chain verification.

How does H33-MPC prevent collusion?

The protocol is designed so that fewer-than-threshold parties learn zero information about the full key, even if they collude. This is an information-theoretic guarantee of secret sharing (Shamir's scheme). Additionally, every session is ML-DSA-attested with a tamper-evident audit trail. Each party's contribution is cryptographically bound to their identity, so collusion attempts are detectable in post-incident forensics.

Is there an audit trail for signing events?

Every finalized MPC session produces a ML-DSA-signed attestation that records the session ID, operation type, threshold configuration, contributing party IDs, timestamp, and result hash. This attestation is cryptographically non-forgeable and post-quantum secure. You can store these attestations in your compliance system for a complete, tamper-proof audit trail of all signing events.

What does post-quantum add to MPC?

Traditional MPC protocols use classical signatures (ECDSA, Ed25519) for attestation, which are vulnerable to quantum computers. H33-MPC attests every session result with Dilithium (ML-DSA), a NIST-standardized post-quantum signature. This means the proof that a signing ceremony occurred correctly will remain valid even after large-scale quantum computers exist. The threshold signing output itself can be classical (for blockchain compatibility) while the attestation is quantum-resistant.

What are the minimum trust assumptions?

H33-MPC assumes an honest majority below the threshold. In a 2-of-3 setup, you need at least 2 honest parties. The H33 server is a coordinator that facilitates message passing but never holds key shares. Session data is stored in an in-memory DashMap with zero persistence to disk. All party contributions are Zeroize-on-drop, meaning memory is cryptographically wiped as soon as the session finalizes.

Can H33-MPC integrate with existing custody platforms?

Yes. The MPC session API is a standard REST interface that custody platforms can call programmatically. Each party in the threshold scheme can be a separate custody service, HSM, or human approver. The /v1/mpc/session/create and /v1/mpc/session/{id}/contribute endpoints accept JSON payloads compatible with standard key-share formats. Integration typically requires adding H33-MPC as a signing backend in your custody platform's key management module.

How much does an MPC session cost?

Each complete MPC session costs 8 credits, which covers session creation, all party contributions, threshold finalization, and ML-DSA attestation. The free tier includes 1,000 credits per month (125 MPC sessions). For high-volume enterprise usage, volume pricing is available. The 8-credit cost is fixed regardless of the number of parties or rounds in the session.

Multi-Party Threshold Signing.
Zero Single Points of Failure.

Four-Phase MPC Session Lifecycle

2-of-3 Threshold Signing Session

MPC Security Architecture

Three Layers of Cryptographic Safety

MPC Session API

Distributed Trust, Zero Single Points

H33-MPC vs. Threshold Signing Alternatives

Frequently Asked Questions

Go Deeper

Start Building With H33-MPC

More in the Privacy & Encryption family

Multi-Party Threshold Signing.Zero Single Points of Failure.

Four-Phase MPC Session Lifecycle

2-of-3 Threshold Signing Session

MPC Security Architecture

Three Layers of Cryptographic Safety

MPC Session API

Distributed Trust, Zero Single Points

H33-MPC vs. Threshold Signing Alternatives

Frequently Asked Questions

Go Deeper

Start Building With H33-MPC

More in the Privacy & Encryption family

Multi-Party Threshold Signing.
Zero Single Points of Failure.