TSS / MPC — Threshold Signatures and Multi-Party Computation

What you’ll get here

the operational, audit-facing view of how Smart Engines signs blockchain transactions without any single machine ever holding a complete signing key — the ceremony, the signing round, the two cryptosystems in play, and the recovery story. For the from-first-principles math, read the DKG & TSS concept; this page is the security reference that sits on top of it.

Traditional blockchain signing needs one private key to authorize a transaction. That key is a single point of catastrophic failure: steal it and every asset is gone. Smart Engines removes that failure mode with three cooperating primitives.

• Distributed Key Generation (DKG) — a key is born split across validators; the whole key is never assembled.
• Threshold Signature Scheme (TSS) — a quorum of validators co-produce one valid signature using their shares.
• Multi-Party Computation (MPC) — the cryptographic operations run without any party revealing its secret.

🧠 For Normies

Imagine a vault that needs several managers turning their keys at the same time — and the master key was shredded at manufacture so it never existed whole. DKG is “manufacture the key already shredded.” TSS is “open the vault with enough partial turns, no whole key ever reassembled.” MPC is the guarantee that no manager ever sees another’s key in the process.

---

Why not just guard one key very well?

%%{init: {'flowchart':{'htmlLabels':true,'curve':'basis'}}}%%
flowchart LR
    subgraph Old["Traditional single key"]
      K["🔑 one private key"] --> SPOF["single point of failure<br/><i>stolen → funds lost<br/>lost → funds frozen</i>"]
    end
    subgraph New["Smart Engines TSS"]
      S1["share 1"] & S2["share 2"] & S3["share 3"] & S4["share 4"] & S5["share 5"]
      S1 & S2 & S3 --> Q["any t=3 quorum<br/>→ one valid signature"]
      Q --> OK["no whole signing key ever exists<br/><i>1 share = useless</i>"]
    end

A t-of-N threshold scheme keeps signing available with up to N − t validators offline, and leaks zero authority below the threshold — a single share is information-theoretically useless.

---

Distributed Key Generation (DKG)

DKG creates a shared key where no single party ever knows the complete private key, each party holds only a share, and the public key is known to all. There is no trusted dealer — every participant is simultaneously a dealer (peer-to-peer Shamir with Feldman verifiable secret sharing).

%%{init: {'sequence':{'showSequenceNumbers':false}}}%%
sequenceDiagram
    autonumber
    participant V1 as Validator 1
    participant V2 as Validator 2
    participant V3 as Validator 3
    Note over V1,V3: Phase 1 — each picks a secret polynomial, broadcasts commitments (hide values)
    V1->>V2: encrypted share f₁(2) + commitments
    V1->>V3: encrypted share f₁(3)
    V2->>V1: encrypted share f₂(1) + commitments
    V3->>V1: encrypted share f₃(1) + commitments
    Note over V1,V3: Phase 2–3 — verify every received share against commitments (Feldman VSS)
    V1->>V1: my final share s₁ = Σᵢ fᵢ(1)
    V2->>V2: my final share s₂ = Σᵢ fᵢ(2)
    V3->>V3: my final share s₃ = Σᵢ fᵢ(3)
    Note over V1,V3: Phase 4 — joint public key computed from commitments only.<br/>The joint secret s = Σ aᵢ,₀ is never assembled anywhere.

Ceremony messages travel over the validators’ signed message bus. Each share is sealed to its recipient with ML-KEM-1024; a share that cannot be sealed is withheld, never sent in plaintext. Every validator echoes a digest of the full set of commitments it received and aborts if any two disagree, so a dealer that sends different commitments to different validators stops the ceremony instead of splitting the group key. Each validator also checks that the committee and threshold on the ceremony’s start message match its own view before it contributes anything. The joint secret is never materialized: each validator holds only its own share, and the joint public key is derived from public commitments alone.

🧠 For Normies

Five people jointly create a secret by each contributing a sealed piece — and they can prove to each other that nobody cheated, without anyone seeing the full secret. At the end, the secret exists only as five pieces. The “public key” (the account’s public identity) is computed from the proofs, never from the secret.

Two cryptosystems, one ceremony

Smart Engines runs two independent DKGs per entity, in the same distributed round:

System	Curve	Purpose	On chain?
A — BLS	BLS12-381	Cluster-internal signatures: smart-app claims and app tokens, image manifests, and the derivation of the cluster’s key-encryption key. BLS signatures aggregate many → one.	No — never appears on chain.
B — ed25519	ed25519	The on-chain signing keys. Run N times per entity (one DKG per slot in the native multisig).	Yes — each slot’s joint public key is a KeyList / SignerList entry.

⚠️ Common audit confusion

BLS is used for internal signatures, not for on-chain transactions, and it is not the post-quantum layer: the PQC quorum certificates are ML-DSA-87. On-chain authority on the live chains, Hedera and XRPL, is the chain’s native multisig over ed25519 keys. Do not expect to see BLS keys on a block explorer. Some accounts use each validator’s own per-chain key as one signer of the native multisig instead of a DKG slot key. That key is held whole by its one validator, and it is never enough to sign alone.

---

Threshold signing

Once DKG completes, validators co-sign. On the live chains, every per-entity slot signs with FROST(Ed25519, SHA-512) (RFC 9591), a two-round threshold Schnorr protocol:

%%{init: {'sequence':{'showSequenceNumbers':false}}}%%
sequenceDiagram
    autonumber
    participant Client
    participant Co as Coordinator
    participant S1 as Signer 1
    participant St as Signer t
    participant Chain as Blockchain
    Client->>Co: transaction to sign
    Co->>S1: round 1 — commit request (prepared transaction)
    Co->>St: round 1 — commit request (prepared transaction)
    S1->>S1: check the operation against the public rules, derive the message locally
    St->>St: check the operation against the public rules, derive the message locally
    S1-->>Co: nonce commitment
    St-->>Co: nonce commitment
    Co->>S1: round 2 — commitment list (no transaction bytes)
    Co->>St: round 2 — commitment list (no transaction bytes)
    S1-->>Co: signature share (from share s₁)
    St-->>Co: signature share (from share s_t)
    Co->>Co: aggregate → one signature, verify under the slot public key
    Co->>Chain: submit multi-signed transaction
    Chain->>Chain: verify against native multisig threshold
    Chain-->>Client: success

• The slot secret is never reconstructed. No raw share crosses the wire, and the coordinator only sums commitments and signature shares. The result is a standard ed25519 signature that verifies under the slot’s existing public key.
• Gate equals sign. Each signer derives the message it signs from the transaction it checked against the rules, not from bytes the coordinator supplies in round 2. A rogue coordinator cannot get a transaction approved and a different one signed.
• Nonces are single-use. A signer deletes its session as soon as it produces its share, so a replayed round-2 request yields no second share.

The internal BLS system signs by aggregating partial signatures, so it never reconstructs its group secret either.

🧠 For Normies

Each validator produces a partial signature with its piece of the key. The partials combine into one final signature that looks exactly like one person signed it. The full signing key is never put back together — not in memory, not on disk, not on the network.

What a validator will agree to co-sign

The co-signing path is deliberately not a general-purpose signing oracle. A compromised validator can drive the in-process signing coordinator directly — it never has to call an HTTP route — so the honest peers it asks for partials are the control that matters. Before a peer emits a BLS partial, it classifies the requested message against an allowlist of legitimate internal signing targets (smart-app claims, Harbor-provision and app-token requests, image manifests, and the reserved credential-derivation domains). Anything matching nothing is refused outright — a bare 32-byte value is not waved through.

The reserved credential-derivation domains get a tighter rule still: they are bound to the one entity entitled to sign them. A peer reconstructs the expected digest for the entity the ceremony names and refuses if it doesn’t match:

• an app’s push-robot credential is co-signable only under that app’s own entity;
• the cluster master-KEK and Harbor admin domains are co-signable only under the governance seed entity, checked against the peer’s own authoritative registry binding — never a value the request claimed.

This closes both the arbitrary-32-byte signing oracle and cross-entity credential reuse (a domain for app V cannot be co-signed under entity W).

The request that reaches a peer, and the partial it returns, ride a signature-authenticated transport: every DKG-share, entity-sign and signature-request message carries an Ed25519 envelope, and the peer binds its sender to the signing key the validator registry pins for that node before the handler runs. An unsigned or wrong-key message is dropped, never classified. This enforcement is unconditional — there is no setting that disables it or lets it accept unsigned requests.

⚠️ Honest residual

this gate validates the payload, not the requester. A validator that is a rightful participant of an entity can still drive that entity’s own ceremony — every validator is such a participant. Constraining that further needs per-caller request authentication; the entity binding does not claim to close it.

---

Multi-chain key support

Chain	Status	On-chain key type	Native multisig primitive
Hedera	Live	ed25519	threshold KeyList
XRPL	Live	ed25519	SignerList + master key disabled
Stellar	Coming next	ed25519	weighted signers + thresholds
Polkadot	Coming next	sr25519	pallet_multisig
Solana	Coming next	ed25519	Squads multisig
Bitcoin	Coming next	secp256k1	P2WSH m-of-n script
Ethereum / EVM	Postponed	secp256k1	none yet

The design rule: prefer the chain’s own native multisig so the ledger — not Smart Engines — verifies the quorum. See Zero Single-Sig for how each chain kills single-sig.

---

Security benefits

1. No single point of failure — an entity’s DKG key never exists whole; one compromised validator holds one share (and, on XRPL, its own signer key), which is below the threshold on its own.
2. Threshold floor enforced by every validator — a validator refuses to join a DKG whose threshold is below a strict majority of the committee, max(2, ⌈(N+1)/2⌉), or whose committee is not its own. That floor is above the coalition a Byzantine-fault-tolerant system tolerates, ⌊(N−1)/3⌋.
3. Share rotation via resharing — membership changes reshare the off-chain shares without changing the on-chain public keys.
4. Post-quantum evidence, in progress — the design pairs each signed transaction with an ML-DSA-87 shadow certificate that customers verify offline. The emit step exists, but no shadow certificate is minted today (Post-Quantum).
5. Auditable policy — every validator checks each operation against rules published on HCS before it contributes a share, so the policy that decided a signature is public.

Threshold selection guidelines

The threshold t of an entity must fall between the floor every validator enforces and the committee size N. When a creation request names no threshold, the platform uses ⌊2N/3⌋+1; a request may name any value in range.

Validators (N)	Lowest threshold a validator accepts	Default when none is named, ⌊2N/3⌋+1	Coalition tolerated by BFT ⌊(N−1)/3⌋
4	3	3	1
5	3	4	1
7	4	5	2
10	6	7	3
21	11	15	6

A higher threshold costs availability: an entity needs t of its N validators online to sign, and at least t of its current holders to reshare.

---

Resharing — pubkeys stay identical

When validators join or leave, the Shamir shares are redistributed for every entity the cluster owns — but the on-chain slot public keys are unchanged, so the native multisig stays bit-identical across rotations.

• Public keys remain unchanged after resharing — existing signatures stay valid.
• No blockchain transaction is required to reshare.
• Resharing runs while the system is operational.
• Every reshare needs a quorum-signed membership decision. Validators refuse a reshare that carries none, and refuse one run by any validator other than the coordinator the decision names.
• Contributions are dealer-signed, and recipients agree on one transcript before anyone stores a new share, so a byzantine coordinator can stall a reshare but cannot forge, alter or mix contributions.

On-chain entity identities and keys never rotate after creation: resharing rotates the off-chain shares, and the on-chain slot public keys stay bit-identical.

🧠 For Normies

When a validator leaves and a new one joins, the secret pieces get reshuffled among the new group — but the account’s public identity on the blockchain never changes. Custody quietly rotates underneath a fixed on-chain face.

---

Emergency recovery

Scenario	What happens today
A validator leaves or fails	Reshare its entities to the remaining validators under a quorum-signed membership decision. A reshare needs at least the old threshold of current holders.
Fewer holders remain than an entity’s threshold	The entity cannot sign, and it cannot be reshared, because a reshare needs the old threshold of holders.
A validator loses its stored shares	There is no on-demand re-delivery yet. The next membership-change reshare that names the validator gives it fresh shares.
Network partition	Signing resumes once a threshold of an entity’s committee can reach each other again.

🧠 For Normies

Recovery never rebuilds a whole key. A lost validator is replaced by reshuffling the pieces among the validators that remain — which is why each entity needs enough healthy holders, at least its threshold, at all times.

---

Best practices

1. Choose thresholds that balance security against availability, at or above the floor validators enforce (a strict majority of the committee).
2. Reshare on every membership change; never let the number of healthy holders approach an entity’s threshold without alerting.
3. Monitor validator health so a quorum is always reachable.
4. Implement signing-session timeouts for stalled rounds.
5. Log every operation; anchor audit records to HCS.
6. Test recovery procedures in staging.

---

Next steps

• DKG & TSS concept — the math from first principles (Shamir → Feldman → DKG → FROST).
• Zero Single-Sig — how each chain’s native multisig enforces the threshold.
• Threat Model — what a rogue validator can and cannot do.
• Post-Quantum — the ML-DSA-87 attestation layer and what it covers today.
• Glossary — DKG, TSS, FROST, Shamir, BFT, multisig defined.