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 on chain, encrypted by the validator consensus public key

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 }
5

The FROST-to-Monero Workflow

Using non-deterministic addresses for non custodial bridge.

DKG Session 1: Generate publicKey_{spend}. Keep shares of privateKey_{spend} distributed and hidden.

DKG Session 2: Generate publicKey_{view}. Immediately trigger a Reconstruction phase to get the full privateKey_{view}.

Address Generation:
Take publicKey_{spend} + publicKey_{view}.
Run them through a Monero address generator (or simple script) to get your 4… address.

Monitoring: Input the Address and the Private View Key (privateKey_{view}) into a wallet like Monero GUI or Feather Wallet. It will now watch the chain for your funds.

Spending: When you want to move money, you construct an unsigned transaction. You feed that data back into your FROST module, the nodes sign it using their privateKey_{spend} shares, and you make the transaction available via query with the final signature for broadcast.

Explanation: non-deterministic monero address are constructed by using the view key and spend key as inputs. The view key and spend keys have no mathematical relationship to each other before being combined to create the non deterministic monero address. Monero transactions sent to the address after combination are able to be viewed with the view key and spent with the spend key.