The Path to Generalized MPC Key Management

1

The Path to Generalized MPC Key Management

The Problem

The network decryption key is a single point of failure.

The Solution Path

Step 1: Solve the internal problem first

Implement MPC key rotation for Secret’s own network decryption key.

Step 2: Generalize the primitive

Once MPC infrastructure exists for internal key rotation, exposing it as a contract-callable primitive is mostly product work. A secret contract should be able to:

  • Generate a new key

  • Hold that key distributed across the validator set

  • Sign arbitrary payloads

Step 3: Chain-agnostic bridges fall out naturally

With generalized MPC key management, bridging any chain becomes straightforward:

Why This Matters

This turns Secret into a universal trust layer. Any organization can externalize key custody to a decentralized, economically-secured MPC network. Any chain can be bridged.

You could run coFHE with this tech

Starting from the same master secret (distributed as MPC shards), you can derive:
Ed25519 keys (for Solana, Stellar, Monero view keys)
ECDSA secp256k1 (for Bitcoin, Ethereum, most EVM chains)
BLS keys (for Ethereum 2.0 validators, some Cosmos chains)
RSA keys (for legacy systems, SSH, some APIs)
Symmetric keys (AES for encrypted data, HMAC for API authentication)
OAuth tokens (derived deterministically for service authentication)

And sign without recombining.

1 Like
3

I BUILT IT!!! TSS uses vote extensions to piggyback on consensus so there there is no extra IO! Signature request callback uses the SUDO entrypoint to send the signature after its aggregated! VERY VERY FUN PROJECT! (i really think this design is elegant) WASM + TSS

FROST TSS Integration for CosmWasm Chains

Repo: GitHub - zenopie/mpc-wasm-chain

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                      WASM CONTRACT                               │
│   CreateKeySet (DKG) ──▶ RequestSignature ──▶ SudoMsg::Complete │
└─────────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────▼───────────────────────────────────┐
│                       TSS MODULE                                 │
│  Vote Extensions: validators include DKG/signing data           │
│  BeginBlocker: process aggregated data, invoke callbacks        │
└─────────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────▼───────────────────────────────────┐
│                   FROST-ED25519 LIBRARY                         │
│  DKG (2 rounds) → Threshold Signing (2 rounds) → Callback       │
└─────────────────────────────────────────────────────────────────┘

Key Design

  1. Vote Extensions carry all TSS data - consensus on DKG/signing state
  2. Contract-Driven - contracts initiate via custom messages, receive signatures via sudo
  3. Automatic Participation - validators participate without manual intervention
  4. Persistent Keys - FROST shares saved to disk, survive restarts

Flow

DKG: Contract → CreateKeySet → 2 rounds via vote extensions → KeySet ACTIVE
Signing: Contract → RequestSignature → 2 rounds → SudoMsg::SignatureComplete { signature }

Usage (Rust)

TSSMsg::CreateKeySet { threshold: 2, max_signers: 3, ... }
TSSMsg::RequestSignature { key_set_id, message_hash, callback }
// Receives: SudoMsg::SignatureComplete { request_id, signature }
4

i also built a full zkVM monero light client for the deposit side