Why We Built Mpcium: The MPC Orchestration Layer Powering Fystack’s Wallet Infrastructure

MPC Libraries Exist, but Real-World Usage Is Painful

In 2024, we were deep in the weeds exploring MPC technology and help Web3 developers improve the security of their wallet systems. Every conversation led to the same question:

“How do we stand up a production MPC cluster quickly… without hiring cryptographers or rewriting half the stack?”

At first, we assumed the answer was simple.
There were already great open-source MPC libraries out there, including tss-lib by Binance, multi-party-ecdsa by Zengo, multi-party-sig by Taurus which we still consider the most important contributions to the ecosystem. Without these projects, MPC adoption wouldn’t be where it is today.

But as we tried to integrate MPC into real applications, we ran into the same wall everyone hits:

> MPC algorithms exist. MPC infrastructure does not

There was no project that helped engineers:

• Provision an MPC cluster
• Handle networking, retries, message ordering
• Manage key shares securely
• Sync nodes across distributed environments
• Integrate MPC with application workflows (examples, tutorials of how to create a wallet, sign transactions)
• Cloud-native deployment using tools like Docker/Kubernetes with reliability guarantees
• Observe and monitor the cluster
• Benchmark performance
• Documentation and tutorials were extremely lacking, and it’s difficult for regular developers to integrate MPC.

If you wanted to use MPC in production, you weren’t just integrating a library
you were building 80% of the system yourself.

Messaging layer? Build it.
Encrypted peer-to-peer communication? Build it.
Authorization flows? Build it.
Key-store? Build it.
Application-layer connectors? Build it.
Deployment automation? Build it.

Meanwhile, most commercial MPC providers expose everything behind a black-box API, this is great if you want convenience, terrible if you want self-hosting, compliance, auditability, or control.

Decision to build on top of tss-lib

Building MPC libraries requires a huge amount of research and engineering effort. Naturally, we didn’t want to reinvent the wheel, brilliant teams have already contributed years of work to this field. After evaluating several MPC libraries, we decided to build on top of tss-lib.

Why we chose tss-lib:

1. Security & Maturity
   tss-lib is one of the most audited and widely used open-source MPC libraries. It’s backed by Binance and battle-tested in production systems like Thorchain. That gave us strong confidence in its cryptographic correctness and operational safety. Even though it still uses GG18, which is an older algorithm and newer schemes like CGGMP21 and DKLs23 already exist, our initial goal was to run experiments rather than optimize for performance. We prioritized adoption, stability, and proven security, so we chose a library that has already been thoroughly battle-tested.

Golang Implementation
tss-lib is written in Go, which aligns perfectly with the strengths of our engineering team. This allowed us to move faster, understand the internals deeply, and contribute safely.

So we began experimenting with building our own wrapper and infrastructure layer around tss-lib. While Binance previously disclosed several vulnerabilities, most have been patched. Like any cryptographic software, there may still be undiscovered issues, and each MPC library has its own implementation details, which can lead to unknown bugs or potential zero-day vulnerabilities.

However, MPC shines when deployed inside private, controlled environments with authorized parties. Because the key is never fully reconstructed and no single node has full signing power, the operational risk is significantly reduced even in the presence of undiscovered bugs.

This is why we confidently chose tss-lib as our foundation, and focused our energy on building the missing piece the ecosystem needs: a production-grade MPC node system with secure messaging, orchestration, and workflow automation.

Mpcium: An experiment turns into a production-ready system

The goal of building our MPC cluster, which we call Mpcium, came from the idea of blending MPC with the reliability philosophies of Ethereum. MPC + Ethereum = Mpcium :)

We deliberately chose technologies that are industry-standard and familiar to enterprise environments, such as NATS for high-performance messaging and Consul for service discovery and health checks.

Using MPCium, developers can spin up a full MPC cluster in just a few minutes on their local machine, making it easy to test, experiment, and understand how MPC fits into real crypto-wallet applications.

What started as a small experiment built in just a few days has evolved, through constant iteration and improvement, into infrastructure that multiple companies now run in production to power real business operations.

Bug fixes and enhancments that we have implemented along the way:

• Node synchronization issues
• Missing or unreliable message durability guarantees
• ECDH-encrypted P2P channels required for protocol-round messages
• Nodes becoming unresponsive under sustained or high-volume load
• Cloud KMS integration
• Backup and recovery

The architecture and technology choice

MPCium is designed to be secure, reliable, and easy to deploy. Here’s how the core architecture works:

• NATS (TLS-encrypted) as the messaging layer, chosen over libp2p for reliability, durability, predictable routing, and automatic failover, which enterprises need.
• Consul (TLS-encrypted) for service discovery, health checks, and cluster coordination.
• ECDH P2P encryption added on top of TLS, creating a second layer of message security even if the network is compromised.
• Ed25519 signature verification on all broadcast messages to ensure authenticity and prevent tampering.
• Encrypted keyshares stored locally in AES-256 BadgerDB inside each MPC node.
• Threshold MPC protocol , ensuring no single node can sign alone.
• Cosign layer backed by KMS or HSM keys, adding hardware-backed validation before any MPC action.
• Optional Authorizers for compliance checks, sanctions screening, or risk scoring, each able to use their own KMS keys for additional trust separation.

Together, this creates a multi-layered security and trust model that is extremely hard to compromise while staying cloud-native, self-hostable, and operationally simple.

Our Philosophy: Not Fully Decentralized, but Fully Secure for Organizations

A lot of folks has been saying that this architecture is centralized and defeats purpose of MPC.

Decentralization is great for public networks, but enterprises don’t need global decentralization.
What they do need is:

• No single point of failure
• Protection against insider compromise
• Protection against social engineering of one engineer
• Reducing unilateral signing power
• Multi-party trust inside the same organization
• Durable infrastructure that survives node failure
• Reliability under heavy load

This is the trade-off we intentionally make:

• Centralized-enough to guarantee reliability
• Decentralized-enough to eliminate single-person risk

This is why MPC works so well for businesses.
You distribute trust across multiple MPC nodes, so no single person or server ever holds a full private key.

Why Not Just Use an HSM?

This is one of the first questions people ask us, and it’s a great one. HSMs are a proven technology, but they solve a different problem than MPC. Here’s the way we explain it:

• HSMs protect a single private key inside one hardware box.
  If that box is misconfigured or compromised, the entire key is at risk. MPC eliminates this single point of failure by distributing trust across multiple nodes.
• HSMs are almost out of reach for the majority of companies and developers.
  They are expensive, require specialized operational knowledge, involve long procurement cycles, and often need physical installation. Most startups, fintech teams, or Web3 builders simply cannot deploy or maintain HSMs at all.
• HSMs don’t scale to modern digital-asset operations.
  They are closed-source, slow to provision, limited in concurrency, and not designed for multi-chain, high-volume signing workflows.
• MPC reduces insider and social-engineering risk.
  No single engineer or server can sign alone. Even if one machine is hacked or one operator is compromised, your assets remain safe, something HSMs alone cannot guarantee.
• HSMs are not designed for cloud-native environments.
  Kubernetes, autoscaling, ephemeral nodes, multi-region deployments, these patterns don’t fit well with physical HSMs. MPCium is designed from day one for containerized, multi-node environments.
• The strongest model is actually MPC + HSM and we support that.
  Our cosign layer lets you require signatures from:
  • Cloud KMS (AWS/GCP/Azure)
  • Hardware HSMs
  • MPC nodes together
    This creates multi-layer trust that is extremely difficult to compromise.
• MPC already dominates institutional custody.
  Fireblocks, Coinbase, Gemini, Anchorage, all rely on MPC because digital assets need distributed trust, automation, and programmable signing workflows. HSMs simply weren’t designed for this world.

Use cases for Mpcium

• Exchange wallet security: MPC-based hot, warm wallets & withdrawal signing without single-key risk.
• Stablecoin operations: Secure mint/burn and treasury actions with multi-party approvals.
• Payment platforms: Automated, policy-driven MPC signing for deposits, payouts, and sweeping.
• Fintech/Web2 integrations: Fast multichain wallet infra without building MPC from scratch.
• DeFi & automation: Secure transaction signing for bots, vaults, and automated strategies.

What’s Next for Mpcium & Fystack

1. Shared-Custody Wallet Model
   A future hybrid MPC model where users and businesses each hold a key share, with the user’s share stored in a mobile app to increase security and decentralization.
2. Mpcium Relayer for Mobile Coordination
   A relayer layer that would allow mobile devices and Mpcium nodes to coordinate keygen, wallet creation, and co-signing, enabling consumer-facing MPC wallets.
3. Protocol-Agnostic MPC Hub
   Mpcium intends to support multiple MPC schemes: GG18, GG20, CGMp21, DKLS23, and emerging algorithms, giving developers freedom in security and performance choices that fit their use case.
4. Advanced Monitoring & Observability
   Roadmap includes real-time MPC session monitoring, health dashboards, latency metrics, and alerting to improve reliability and operator visibility.
5. Native Cloud Deployment & Provisioning Tooling
   A plan to offer tooling for provisioning Mpcium clusters in cloud environments (AWS/GCP/Azure/etc.) to simplify deployment, networking, scaling, and secure configuration.

Sincere thanks to our early contributors:
viettdue, nann-cheng, Poseidon-G, sivo4kin, tuananhk13bk, johnnynanjiang, and many others who supported the project.

Checkout Mpcium documentation: https://docs.fystack.io/mpcium

Fytack is a team specializing in building use cases for MPC. Join our Telegram community to get updates about Fystack and what we are building https://t.me/+9AtC0z8sS79iZjFl