Mpcium MPC Engine

Mpcium is a high-performance, open-source Multi-Party Computation (MPC) engine designed for securely generating and managing cryptographic wallets across distributed nodes. It ensures that the full private key is never exposed by using a threshold signature scheme.

Supported cryptographic schemes include:

• ECDSA (secp256k1): For Bitcoin, Ethereum, BNB, Polygon, and EVM-compatible L2 chains.
• EdDSA (Ed25519): For Solana, Polkadot, Cardano, and other modern blockchains.

Understanding the file layout is critical for backups and manual configuration.

• /opt/mpcium/: Application home (owned by mpcium:mpcium).
  • certs/: TLS certificates (client-cert.pem, client-key.pem, rootCA.pem).
  • db/: BadgerDB storage.
  • backups/: Encrypted backups.
  • identity/: Node identity files (e.g., nodeX_identity.json, nodeX_private.key or nodeX_private.key.age).
  • peers.json: Peer registry.
  • .env: Environment variables.
• /etc/mpcium/: Configuration (owned by root:mpcium).
  • config.yaml: Main configuration file.

Mpcium uses a t-of-n threshold signature scheme where n is the total number of MPC nodes (minimum 3 recommended) and t is the minimum nodes required for operations ($t \ge \text{floor}(n/2) + 1$). Private keys are never fully reconstructed; only $t$ nodes are needed for signing operations.

In an AWS ECS Fargate deployment, each task runs a single node with a unique identity (Ed25519 keypair), encrypted BadgerDB storage on EFS, and connections to NATS (message broker) and Consul (service discovery).

Mpcium utilizes a t-of-n threshold scheme to manage security and fault tolerance.

• n represents the total number of MPC nodes (key shares).
• t represents the minimum number of nodes required to successfully sign a transaction.

To prevent a single point of compromise, Mpcium enforces the security property: t ≥ ⌊n / 2⌋ + 1

Example (2-of-3 Threshold): In a cluster where n=3 and t=2:

• node0 + node1 can sign successfully.
• node1 + node2 can sign successfully.
• node0 alone cannot sign.

This configuration ensures that even if some nodes go offline, the system remains functional, and even if a node is compromised, the full key remains secure.

When running multiple client instances against the same MPC cluster, you must set a unique ClientID in the client.Options.

Without a unique ClientID, concurrent requests from different clients may cause a race condition where one client receives the result intended for another.

• Scope: ClientID scopes the NATS consumer and result subject.
• Allowed characters: Alphanumeric, hyphens (-), and underscores (_).
• Default: If only one client instance is running, ClientID can be an empty string.

Mpcium operates on a $t$-of-$n$ threshold signature scheme. This means that in a cluster of $n$ total MPC nodes, a minimum of $t$ nodes must collaborate to perform cryptographic operations (like signing or key generation).

Key properties:

• $n$ (Total Nodes): The total number of nodes in the cluster. A minimum of 3 nodes is recommended for production.
• $t$ (Threshold): The minimum number of nodes required for operations. It is calculated as $t \ge \lfloor n/2 \rfloor + 1$.
• Security: Private keys are never fully reconstructed on any single node; only $t$ nodes are needed to complete a signing operation.

Each node requires a unique Ed25519 identity, encrypted BadgerDB storage, and connections to NATS (for messaging) and Consul (for service discovery).

The chain_code is a mandatory 32-byte cryptographic parameter (represented as a 64-character hexadecimal string) used for Hierarchical Deterministic (HD) wallet functionality.

Critical Requirement: All nodes in your MPC cluster MUST use the identical chain_code value. If the values differ or are missing, nodes will fail to start.

To generate a new code and apply it to the main configuration and all node directories, use the following pattern:

# Generate a random 32-byte chain code and save it
CC=$(openssl rand -hex 32) && echo "$CC" > .chain_code

# Apply to main config
sed -i -E "s|^([[:space:]]*chain_code:).*|\1 \"$CC\"|" config.yaml

# Apply to all node configs (example for 3 nodes)
for n in node0 node1 node2; do
  sed -i -E "s|^([[:space:]]*chain_code:).*|\1 \"$CC\"|" "$n/config.yaml"
done

Each ECS task is composed of four containers to manage the lifecycle of secrets, configuration, and data:

1. init-secrets: Pulls passwords from AWS Secrets Manager and writes them to the /secrets/ volume.
2. init-config: Downloads config.yaml, peers.json, and identity files from S3.
3. init-data: Copies identity files and peers.json from ephemeral volumes to EFS (/app/data/) to ensure persistence across restarts.
4. mpcium: The main application container (distroless, no shell).

Complete the security setup by generating a random chain code and unique BadgerDB passwords for each node.

Generate Chain Code

CHAIN_CODE=$(openssl rand -hex 32)
echo "Chain code: $CHAIN_CODE"

Generate BadgerDB Passwords

Generate a 16-character alphanumeric password for each node's database:

for node in node0 node1 node2; do
  PASSWORD=$(< /dev/urandom tr -dc 'A-Za-z0-9!@#$' | head -c 16; echo)
  echo "$node BadgerDB password: $PASSWORD"
done