​
Deep Dive: 2-of-3 MPC Key Management with zkMPC

Refract’s wallet infrastructure provides users with a fully self-custodial wallet secured by advanced Multi-Party Computation (MPC). We utilize the cggmp-24 threshold-ECDSA scheme to ensure that a user’s complete private key is never materialized or stored in a single location, providing robust security against theft and unauthorized access.

​
Architecture Overview

The protocol divides a user’s private key into three distinct, mathematically-linked shares, or “shards.” To authorize any transaction, at least two of these three shards must be used in a cryptographic signing ceremony.

​
The Three Key Shards

  1. Client Shard (xC): This shard lives securely on the user’s device within the Refract Passport client environment. It is the key that proves the user’s physical presence and intent to sign. Without this shard, no transaction can be initiated.

  2. Enclave Shard (xS): This shard is managed by Refract’s backend but is securely sealed within an AWS Nitro Trusted Execution Environment (TEE). The TEE acts as a black box, ensuring that even Refract’s own infrastructure cannot access or misuse this shard. It participates in the signing ceremony only after validating the user’s authentication.

  3. Recovery Shard (xR): This is the user’s backup. It is encrypted with a high-entropy, 8-digit passcode that only the user knows. The user can download this shard and store it in a safe place (e.g., a password manager). Refract can optionally store an encrypted copy for the user, but we have no ability to decrypt it.

​
Wallet Creation Flow

When a new user signs up, the wallet creation process uses the CGGMP-24 distributed key generation (DKG) protocol.

  1. Initialization: The user authenticates with their social identity (e.g., via TikTok or Telegram) through Refract Passport. Our backend verifies this is a new user.
  2. Secret Generation: The Refract Passport client generates two secret values, while the Refract backend generates one.
  3. DKG Ceremony: The client and backend engage in a multi-step cryptographic protocol (commit -> share -> verify -> output).
  4. Output: The ceremony concludes by outputting the three key shards (xC, xS, xR) to their respective locations. Critically, the full private key is never constructed on any single machine during this process.

​
Transaction Signing Flow

  1. User Approval: A dApp requests a transaction. The user approves it in the Refract Passport UI.
  2. Authentication: The Passport client authenticates with the Refract backend, proving the user’s identity.
  3. 2-of-3 MPC Signature: The Passport client (holding xC) and the backend Nitro Enclave (holding xS) perform a single round-trip communication using the CGGMP-24 signing protocol.
  4. Result: The process produces a valid ECDSA signature, which is returned to the client to be broadcast to the blockchain. The full private key remains un-materialized. This distributed process ensures that neither a compromised device nor a compromised server alone is sufficient to forge a transaction.