Hanzo

Hanzo MPC

Enterprise-grade multi-party computation for digital asset custody with 8 cryptographic protocols, configurable t-of-n thresholds, and multi-chain support.

Hanzo MPC

Hanzo MPC is a self-sovereign wallet infrastructure for enterprise digital asset custody. It eliminates single points of failure by splitting private keys into shares distributed across independent nodes, requiring a configurable threshold of cooperating parties to produce valid signatures.

Think of it as a self-hosted alternative to Fireblocks -- you own the infrastructure, control the key shares, and operate under your own security policies.

Key Properties

  • No single point of failure: No individual node ever holds a complete private key
  • Configurable thresholds: Any t-of-n scheme (2-of-3, 3-of-5, 5-of-9, etc.)
  • Identifiable aborts: Malicious participants are detected and attributed
  • Proactive share refresh: Rotate key shares without changing the public key or address
  • Multi-chain: 16+ blockchain networks from a single key management plane
  • 8 cryptographic protocols: From production ECDSA to post-quantum lattice signatures
  • 17 zero-knowledge proof systems: Comprehensive verification at every protocol stage
  • Encrypted at rest: AES-256-GCM for all stored key shares

Quick Start

Create a Wallet

curl -X POST https://mpc.hanzo.ai/api/wallets \
  -H "Authorization: Bearer $HANZO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "protocol": "cggmp21",
    "curve": "secp256k1",
    "threshold": 2,
    "parties": 3,
    "label": "eth-hot-wallet"
  }'

Response:

{
  "wallet_id": "w_3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "protocol": "cggmp21",
  "curve": "secp256k1",
  "threshold": 2,
  "parties": 3,
  "public_key": "04a1b2c3d4e5f6...",
  "addresses": {
    "ethereum": "0x742d35Cc6634C0532925a3b844Bc9e7595f2bD18",
    "bitcoin": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh"
  },
  "created_at": "2026-02-23T10:30:00Z"
}

Sign a Transaction

curl -X POST https://mpc.hanzo.ai/api/sign \
  -H "Authorization: Bearer $HANZO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet_id": "w_3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "message": "0xdeadbeef...",
    "encoding": "hex"
  }'

Response:

{
  "signature": {
    "r": "0x1a2b3c...",
    "s": "0x4d5e6f...",
    "v": 27
  },
  "signers": [1, 3],
  "protocol": "cggmp21",
  "duration_ms": 45
}

Reshare Key Shares

Rotate shares without changing the public key or any on-chain addresses:

curl -X POST https://mpc.hanzo.ai/api/reshare \
  -H "Authorization: Bearer $HANZO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet_id": "w_3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "new_threshold": 3,
    "new_parties": 5
  }'

Supported Protocols

Hanzo MPC ships 8 cryptographic protocols, each optimized for different use cases:

ProtocolTypeCurveBest For
CGGMP21Threshold ECDSAsecp256k1, P-256Bitcoin, Ethereum, EVM chains
FROSTThreshold Schnorr/EdDSAEd25519, RistrettoSolana, Polkadot, Cosmos
LSSSLinear secret sharingAnyDynamic resharing, key rotation
TFHEThreshold FHELatticeEncrypted computation on shares
RingtailPost-quantum latticeModule-LWEFuture-proof custody
QuasarHybrid BLS + PQBLS12-381 + DilithiumEthereum 2.0, PQ hedge
BLSAggregate signaturesBLS12-381Validator keys, aggregate sigs
DoernerOptimized 2-of-2secp256k1High-frequency 2-party signing

See the Protocols deep dive for detailed specifications.

Multi-Chain Support

A single MPC wallet can derive addresses for any supported chain:

ChainCurveProtocolNotes
Bitcoinsecp256k1CGGMP21Legacy, SegWit, Native SegWit
Bitcoin Taprootsecp256k1 (BIP-340)FROSTSchnorr signatures
Ethereumsecp256k1CGGMP21EIP-155 replay protection
All EVM chainssecp256k1CGGMP21Polygon, Arbitrum, BNB, etc.
SolanaEd25519FROSTSPL token support
TONEd25519FROST
CardanoEd25519FROSTByron and Shelley
NEAREd25519FROST
PolkadotSr25519FROSTSubstrate chains
Cosmossecp256k1CGGMP21IBC-compatible
Lux Networksecp256k1CGGMP21X/P/C chains
XRPLsecp256k1CGGMP21
BNB Chainsecp256k1CGGMP21BSC and BNB Beacon
Polygonsecp256k1CGGMP21PoS and zkEVM
Arbitrumsecp256k1CGGMP21L2 rollup
Ethereum 2.0BLS12-381BLS / QuasarValidator signing

Performance

Real benchmarks from production clusters:

FROST Key Generation

PartiesTimeNotes
322 msTypical hot wallet
1038 msTeam custody
20332 msInstitutional
30535 msLarge consortium
501.85 sDAO governance

FROST Signing

SignersTimeNotes
325 msStandard threshold
521 msBatch-optimized

Signing is O(t) -- it depends only on the threshold, not the total number of parties. A 3-of-100 wallet signs just as fast as a 3-of-3.

Cryptographic Primitives

OperationThroughput
Scalar multiplication23 us/op
Lagrange interpolationO(n^2)
Polynomial evaluationO(n * t)
Keygen communicationO(n^2) rounds

Architecture

                    ┌──────────────────────────────────┐
                    │         Client / KMS              │
                    │  (REST API + Bearer Auth)          │
                    └──────────────┬───────────────────┘

                    ┌──────────────▼───────────────────┐
                    │       MPC Coordinator             │
                    │  - Protocol orchestration          │
                    │  - IAM token validation            │
                    │  - Audit logging                   │
                    └──────────────┬───────────────────┘
                                   │ NATS JetStream
                    ┌──────────────▼───────────────────┐
                    │         MPC Nodes (StatefulSet)    │
                    │                                    │
                    │  ┌────────┐ ┌────────┐ ┌────────┐ │
                    │  │ Node 0 │ │ Node 1 │ │ Node 2 │ │
                    │  │ share₀ │ │ share₁ │ │ share₂ │ │
                    │  └────┬───┘ └────┬───┘ └────┬───┘ │
                    │       │          │          │      │
                    │  ┌────▼──────────▼──────────▼───┐ │
                    │  │    BadgerDB (encrypted)       │ │
                    │  │    AES-256-GCM per node       │ │
                    │  └──────────────────────────────┘ │
                    └──────────────────────────────────┘

                    ┌──────────────▼───────────────────┐
                    │       Consul Service Mesh          │
                    │  - Peer discovery                  │
                    │  - Health checks                   │
                    │  - mTLS between nodes              │
                    └──────────────────────────────────┘

Components

ComponentTechnologyPurpose
CoordinatorGoProtocol orchestration, API gateway
MPC NodesGo + Rust (crypto)Key share storage, protocol execution
Message BusNATS JetStreamReliable inter-node messaging
DiscoveryConsulPeer discovery, health, mTLS
StorageBadgerDBEncrypted key share persistence
AuthHanzo IAM (hanzo.id)Bearer token validation, RBAC

Authentication

All API requests require a Bearer token issued by Hanzo IAM:

# Obtain token from Hanzo IAM
TOKEN=$(curl -s https://hanzo.id/api/login \
  -d '{"username":"admin@example.com","password":"..."}' | jq -r .token)

# Use with MPC API
curl -H "Authorization: Bearer $TOKEN" \
  https://mpc.hanzo.ai/api/wallets

See Hanzo IAM for full authentication documentation.

Security Model

Key Share Isolation

  • Each node runs in its own Kubernetes pod with dedicated persistent volume
  • Shares are encrypted at rest with AES-256-GCM using node-specific keys
  • Node-to-node communication uses mTLS via Consul Connect
  • No single node ever holds enough information to reconstruct a private key

Zero-Knowledge Proofs

17 ZK proof systems verify correctness at every protocol stage:

  • Schnorr proofs of discrete log knowledge
  • Paillier encryption correctness proofs
  • Range proofs for secret share values
  • Commitment consistency proofs
  • Feldman VSS verification
  • Pedersen commitment proofs

Identifiable Aborts

If any participant deviates from the protocol, the system:

  1. Detects the deviation through ZK verification
  2. Identifies the specific malicious party
  3. Aborts the operation with a signed blame proof
  4. Logs the incident to the audit trail

Proactive Share Refresh

Key shares can be refreshed on a schedule or on-demand without changing the underlying key:

  • Old shares become useless after refresh
  • Compromised shares from a past epoch cannot be combined with current shares
  • The public key and all derived addresses remain unchanged

Next Steps

Deep dive into all 8 cryptographic protocols

Complete REST API documentation

Helm charts, Docker, and Kubernetes setup

Use MPC as a signing backend for Hanzo KMS

How is this guide?

Last updated on

On this page