Skip to main content

Key Concepts

This page explains how Silent Shard Trio works: the components you run, the signing parties, the storage that holds keyshares, key refresh, recovery, and the deployment setups. If you are new to MPC, start with the Introduction.

How the parties communicate

Silent Shard Trio is a three-party MPC wallet. No complete private key exists anywhere: the key is split across three parties, and a threshold of them cooperate to sign. The parties run an interactive protocol over a session, exchanging a sequence of messages (rounds). Each party computes on its own secret and contributes the result, so no party reveals its secret and the full key is never assembled.

After key generation, each party holds its own keyshare. In the common 2-of-3 (hybrid) setup, two of the three sign, and the third provides backup, recovery, and fault tolerance.

Signing

To sign, the required parties run a signing exchange: each contributes a partial computation from its own share alone, and the results combine into a single, standard signature. Because the key is never reconstructed, no single party can sign alone, and in the 2-of-3 setup the wallet keeps working even if one party is unavailable.

Key refresh

Key refresh rotates all three shares for the same wallet. The address does not change, but the previous shares no longer match the new ones, so they are invalidated and can no longer be used for signing.

Other operations

Beyond keygen, sign, and refresh, the SDK covers the rest of a wallet's lifecycle:

  • BIP32 derivation: derive child keys from a wallet along a derivation path, so one wallet can produce many addresses.
  • Import key: bring an existing private key into an MPC wallet by splitting it across the parties.
  • Export key: reconstruct and export the full private key by combining the shares. Gate this behind strong user authentication.
  • Pre-sign: precompute signing material ahead of time so the final signature is produced faster when you need it.

Key recovery

Trio's third share makes recovery possible. If a user loses their device and has no usable backup, the second cloud node, which took part in the original key generation, cooperates with a new device to regenerate the lost share through an MPC recovery protocol, without revealing it to any party.

The storage client

The SDK reads and writes keyshares through a storage client that you provide. The SDK ships SimpleStorageClient, an in-memory implementation for tests and development; production apps supply a persistent one.

Reconcile vs. no-reconcile

A newly generated share starts in a Pending state and must be Committed before it's the wallet's live share. With reconcile (default), the parties run one extra confirmation round before committing, so they can't fall out of sync. With no-reconcile, they commit directly with no extra round. This is faster, and persisting the new share becomes the client's responsibility.

Deployment setups

The protocol is identical in both setups; the difference is where the parties run.

Trio-h, hybrid (device + two cloud nodes)

One share runs on the user's device; two run as cloud nodes at the wallet provider. Signing needs the device plus one cloud node (2-of-3), and the second cloud node enables recovery if the device is lost. This is the common setup.

Loading Diagram...

Trio-c, cloud (three nodes)

Three cloud nodes, on-prem or third-party, run the protocol among themselves.

Loading Diagram...

Transport security

Messages exchanged between the parties are end-to-end encrypted. See the Security Model for the guarantees and threat model.

Next steps