BenchmarksStack Ranking
H33-VaultH33-ShareH33-ShieldH33-HealthH33-KeyH33-128H33-CKKSH33-256H33-FHE-IQFHE OverviewH33-CompileZK LookupsBiometricsH33-3-KeyH33-MPCZK-TrustlessZK-PhishZK-VerifyPQC ArchitecturePQ VideoStorage EncryptionAI DetectionEncrypted Search
APIsPricingDocsWhite PaperTokenBlogAboutSecurity Demo
Log InGet API Key
THRESHOLD SIGNING · POST-QUANTUM

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

Multi-party key generation, signing, and resharing with Dilithium (ML-DSA) attestation. Configurable N-of-M threshold. No single party ever holds the complete key.

Get API Key → API Docs Compare H33-3-Key
N-of-M
Threshold
ML-DSA
Attestation
Zero
Single Point
8
Credits/Session
PIPELINE

Four-Phase MPC Session Lifecycle

Create a session, collect contributions from each party, finalize with threshold combination, and receive a Dilithium-attested result. All contributions are zeroed from memory on completion.

1 Create
Session Init
Define the operation (Sign, KeyGen, or Reshare), set the N-of-M threshold, and specify participating parties. Session ID returned immediately.
Sign KeyGen Reshare N-of-M
→
2 Contribute
Party Shares
Each party submits their key share or signature fragment. Contributions are validated and stored with Zeroize-on-drop memory safety. Multi-round support for complex protocols.
Per-party Zeroize Multi-round
→
3 Finalize
Threshold Combine
Once threshold is met, contributions are combined. Sign operations proxy to gRPC gateway. KeyGen and Reshare combine locally via SHA3 hash. Result is Dilithium-signed.
gRPC proxy SHA3 Dilithium
→
4 Attested
PQ-Signed Result
Final result carries a Dilithium (ML-DSA) signature attesting the computation was performed correctly. All party contributions are zeroed from memory. Session marked complete.
ML-DSA FIPS 204 Memory-safe
MPC Session
8 credits per session
Dilithium attestation included
LIVE DEMO

2-of-3 Threshold Signing Session

Watch a complete MPC signing flow. Three parties hold key shares. Only two are needed to produce a valid Dilithium-attested signature. The full key is never reconstructed.

Create Session
Initialize 2-of-3 signing session. Operation: Sign. Parties: Alice, Bob, Carol.
POST /v1/mpc/session/create → mpc_abc123
Party Alice Contributes
Alice submits her key share (round 1). Payload validated. Stored with Zeroize-on-drop. 1 of 2 needed.
POST /v1/mpc/session/mpc_abc123/contribute
Party Bob Contributes
Bob submits his key share (round 1). Threshold met (2 of 2). Session transitions to ReadyToFinalize.
Phase: AwaitingContributions → ReadyToFinalize
Finalize & Combine
Shares combined via gRPC gateway proxy (127.0.0.1:50052). Threshold signature produced. Carol's share was never needed.
gRPC round-trip < 5ms
Dilithium Attest
Result signed with Dilithium-5 (ML-DSA, NIST Level 5). 3,309-byte PQ signature. ~191 µs sign+verify.
Dilithium sign + verify: ~191 µs
Session Complete
All party contributions zeroed from memory. Session marked Finalized. PQ-attested signature returned.
Total: < 50ms (local network)
{ "phase": "Finalized", "result": "base64_threshold_signature...", "attestation": { "algorithm": "Dilithium-5 (ML-DSA)", "signature": "3,309 bytes", "session_id": "mpc_abc123", "parties_contributed": ["alice", "bob"], "threshold": "2-of-3" }, "contributions_zeroed": true }
SECURITY

MPC Security Architecture

Every MPC session is memory-safe, post-quantum attested, and designed with zero persistence. Party contributions never touch disk.

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 Dilithium-5 attestation (NIST Level 5)
SECURITY GUARANTEES

Three Layers of Cryptographic Safety

H33-MPC is built on information-theoretic security, post-quantum cryptography, and memory-safe Rust. No single compromise can break the system.

Collusion Resistance
Fewer-than-threshold parties learn zero information about the full signing key, even if they collude and share all their data. This is an information-theoretic guarantee of Shamir's secret sharing — not a computational assumption that could be broken by faster hardware.
Threshold t of n → any t-1 colluding parties gain 0 bits of information about the key. Guarantee: unconditional.
Quantum Resistance
Every finalized MPC session carries a Dilithium-5 (ML-DSA) signature — the strongest level of NIST's post-quantum standard (FIPS 204). Even when large-scale quantum computers arrive, the attestation that your signing ceremony occurred correctly remains cryptographically valid.
ML-DSA Level 5 • 3,309 B signatures • ~191 µs sign+verify • NIST FIPS 204
Memory Safety
Party contributions implement Zeroize and ZeroizeOnDrop — every byte of key material is cryptographically wiped from RAM the instant a session finalizes or a struct is dropped. Sessions live in DashMap (in-memory only). Nothing touches disk. Nothing persists after use.
Rust • Zeroize + ZeroizeOnDrop • DashMap • 0 disk writes • 0 key persistence
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 Dilithium 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 (Dilithium-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": "Dilithium-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": "Dilithium-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
# - Dilithium attestation on reshare event
Use Cases

Distributed Trust, Zero Single Points

H33-MPC eliminates single points of failure in key management. No single party ever holds the complete signing key — threshold combination is required for every operation.

Distributed Custody
No single key holder. Split signing authority across multiple custodians, geographies, or compliance domains. A compromised party cannot sign alone. Ideal for institutional digital asset custody.
Multi-Sig Governance
DAO treasury operations, board approvals, and multi-stakeholder governance. Configurable 2-of-3, 3-of-5, or any N-of-M threshold. Every finalized action carries Dilithium attestation.
Key Rotation Without Downtime
Reshare operation redistributes key shares to a new set of parties without ever reconstructing the full key. Zero downtime during rotation. Old shares become cryptographically useless.
Regulatory Compliance
Segregation of signing authority meets regulatory requirements for financial services, healthcare, and government. Auditable session logs with post-quantum attestation on every operation.
COMPARISON

H33-MPC vs. Threshold Signing Alternatives

Feature-by-feature comparison against leading threshold signing and MPC platforms.

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 Dilithium-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 Dilithium attestation) typically completes in under 50 milliseconds for local network scenarios. The dominant cost is the Dilithium 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 Dilithium 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 Dilithium-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 Dilithium-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 Dilithium 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.
TECHNICAL DEEP DIVES

Go Deeper

🔀 MPC vs FHE
Secure MPC vs FHE: When to Use Which
Multi-party computation and homomorphic encryption solve different problems. Here's the decision framework.
Read Full Article →
✍️ SIGNATURES
CRYSTALS-Dilithium Digital Signatures
H33-MPC uses Dilithium attestation for every threshold operation. Deep dive into the ML-DSA standard.
Read Full Article →
🔑 KEY MGMT
Cryptographic Key Management
Threshold signing, key resharing, and rotation — managing distributed keys securely across multiple parties.
Read Full Article →

Start Building With H33-MPC

Post-quantum threshold signing with Dilithium attestation. 8 credits per session. Free tier included.

Get Free API Key → API Documentation
Verify It Yourself