MPC: The Key That Never Exists

Let me start with a thought experiment.

Imagine you're responsible for a wallet. Not a personal one. An institutional-grade wallet address holding hundreds of millions of dollars in digital assets for clients. Banks. Funds. Custodians.

Now imagine that somewhere, in a file, on a server, exists a single string of characters. 64 hexadecimal characters. And if anyone gets hold of that string, a hacker, a rogue employee, a phishing email that landed at the wrong moment, everything in that wallet is gone. Instantly. Irreversibly. With no recourse whatsoever.

That's the reality of traditional private key custody. And it's exactly the problem I was working around at io.finnet.

I want to be upfront about something before we go further. I didn't build the cryptography. That was a different team, people far smarter than me in the mathematics of secure computation. What I built was the product around it: the frontend signing flows, the backend APIs, the dashboards that institutional clients actually touched. And somewhere in that process, without really planning to, I learned enough about MPC to have a genuine opinion on it. This is that opinion.

The problem with secrets

Before MPC, digital asset custody had two main approaches.

Single private key. Simple. Fast. And catastrophically fragile. One key, one point of failure. Fine for a personal wallet. Not fine when you're holding assets for a hedge fund.

Multisig. A real step forward. Instead of one key, you need multiple independent keys to sign a transaction. Like a bank vault that requires two people to turn two different locks at the same time. Better, but with genuine operational pain attached. Each signer shows up visibly on-chain, which creates privacy concerns. Transaction costs also increase with each additional signer, since more signers means larger transaction sizes and higher fees. It's chain-specific, so good luck using Ethereum multisig on Bitcoin. And operationally it's clunky: changing signers means changing contracts, rotating keys is painful, and the whole thing doesn't scale well across multiple chains.

The industry needed something better. Something that distributed control without the on-chain overhead. Something where the private key itself was never the weak link.

That something is MPC. And funnily enough, the idea had been sitting in academic papers since the 1980s. It just took crypto to make anyone care enough to use it.

A 40-year-old idea that finally found its moment

In 1982, a computer scientist called Andrew Yao formalised the concept to solve what researchers called the Millionaires' Problem: two people want to know who is richer without either of them revealing their actual wealth. The maths worked. The concept was elegant. And then it went largely unused for decades because nobody could make it fast enough to matter in the real world.

Early implementations were computationally brutal. Too slow, too expensive, too much back-and-forth between parties. People kept looking at MPC and concluding it wasn't worth the hassle.

Then digital assets arrived. Private key custody was costing institutions real money through hacks and insider theft, and the stakes were suddenly high enough that the tradeoffs made sense. By the late 2010s, custodians were using it in production. The industry that had been duct-taping private key management together with hardware wallets and crossed fingers finally had something better to reach for.

What MPC actually is

MPC stands for Multi-Party Computation. It's a broad field of cryptography covering many different techniques for letting multiple parties jointly compute something without revealing their individual inputs. The academic definition is dense, so let's do the plain version.

What the custody industry actually uses is a specific sub-field called TSS (Threshold Signature Schemes). You'll often see this written as MPC-TSS, which is more precise. When people in the crypto space say "MPC," they usually mean MPC-TSS: the application of multi-party computation specifically to the problem of producing digital signatures. That's the thing worth understanding.

Think of it like a secret family recipe. Instead of writing the full recipe on one piece of paper that could get lost or stolen, you split it into three parts and give each part to a different family member. No single person has the whole recipe. But if you need to cook, you bring your parts together, make the dish, and then everyone goes home with their piece still in their pocket. The full recipe was never written down in one place. It existed only for the moment it was needed, and only as the finished meal.

MPC works the same way, just with mathematics instead of grandma's lasagne.

In a traditional wallet, there's a private key. A number. Whoever has that number controls the funds. MPC replaces that model entirely.

Instead of generating one private key, MPC splits the material that would become a key into multiple shares, distributed across different parties or devices. Here's the part that took me a moment to fully absorb: the full private key never exists, anywhere, at any point in time. Not during generation. Not during signing. Not ever.

When a transaction needs to be signed, each party uses their share to perform a piece of the computation locally. The results are combined mathematically to produce a valid signature, the exact same signature the blockchain expects, indistinguishable from one produced by a single key. The blockchain has no idea what happened behind the scenes. It just sees a valid signature and processes the transaction.

The key that secured the transaction never existed. The math produced the proof without ever requiring the secret to be whole.

The threshold model adds another layer of resilience on top of that. Rather than a simple headcount, signers can carry different weights. Imagine three people: Signer A, Signer B, and Signer C. The threshold to approve a transaction is set to 3. Signer A has a signing power of 3, so they can approve a transaction entirely on their own. Signer B and Signer C each have a signing power of 2, meaning either of them needs one other person to co-sign before anything goes through. It's not about how many people are in the room. It's about how much trust has been assigned to each of them. Lose a signer? As long as the remaining shares can reach the threshold, the system keeps working.

What it looks like from the product side

This is where I can speak from real experience.

At io.finnet, the MPC infrastructure is owned by a dedicated cryptography team. My job, along with the broader product team, was to build the layer that humans and systems actually interact with.

What does that look like day to day?

A signer gets a push notification on their mobile app. They authenticate with a passcode, Face ID, or fingerprint. They review the transaction details. They approve. Behind the scenes, their device has just participated in an MPC signing ceremony, contributing their key share to a threshold computation. They never see a private key. They never could see a private key. There isn't one to see.

On the backend, we built APIs that orchestrate these signing flows: routing approval requests to the right signers, collecting responses, assembling the final transaction. The platform enforces the rules around who needs to sign, what transaction limits apply, and what happens when a signer is unavailable.

One feature I found particularly interesting to build around was the Virtual Signer. An automated signing participant that can approve transactions based on predefined policies without any human in the loop. For high-frequency, rules-based operations like automated treasury rebalancing or recurring settlements, you don't want a human approving every transaction at 3am. The Virtual Signer handles it, within the guardrails the institution has already agreed on. It's one of those features that sounds simple until you think about how much trust has to be encoded into the rules for it to work safely.

What struck me building across these layers was how invisible the MPC layer actually is from the product side. You don't interact with it directly. You build flows that collect human intent: approve this transaction, with these parameters, from this account, and the infrastructure handles the rest. The cryptographic ceremony happens entirely behind the scenes.

That's the mark of well-designed infrastructure. The hard thing disappears.

MPC vs multisig: the honest comparison

I've seen a lot of marketing material that positions MPC as universally superior to multisig. The reality is more nuanced than that.

Both models distribute control. Neither relies on a single key holder. But they make very different tradeoffs.

The key tension is this: multisig enforces its rules on-chain. Everything is transparent, verifiable, public. For a DAO voting on treasury decisions, that transparency is a feature. It's the whole point. For a bank managing client assets across twelve different blockchains, you don't want your approval policy visible to the world, and you definitely don't want to pay smart contract gas costs on every single transaction.

MPC moves the policy enforcement off-chain. That's operationally powerful. You can update signers, rotate shares, and change thresholds without touching wallet addresses. But it means your audit trail lives in your own systems. You need strong internal controls and logging. The compliance burden shifts inward.

Neither approach is wrong. They're optimised for different contexts.

The parts that don't make the marketing slides

I'd be doing you a disservice if I only told the good parts.

I'm not a cryptographer. I can't audit the maths. What I can tell you is that MPC is only as good as the implementation behind it. The theory is sound. The practice is hard. And not all MPC providers are built the same way.

Some providers hold one or more of the key shares themselves, which quietly reintroduces the custodial risk the whole thing was supposed to eliminate. That's a design choice, not a guarantee that comes with the MPC label. Worth reading the small print before you trust it with anything that matters.

There's also a coordination cost. Getting multiple parties to participate in a signing ceremony takes time. In an institutional custody context that's a perfectly acceptable tradeoff. In a high-frequency trading environment where milliseconds matter, it's a different conversation. MPC is genuinely exceptional for what it was built for. It is not the answer to everything.

Where this is all going

The SEC approved eleven spot Bitcoin ETFs in January 2024 (Congress.gov). What followed was a lot more institutional money moving into crypto than most people expected. Professional investors (tracked through 13-F filings) held $27.4 billion worth of Bitcoin ETFs by Q4 2024, a 114% increase in a single quarter (CoinShares). That kind of capital doesn't move without institutional-grade custody behind it. MPC-TSS fits those requirements in a way that neither hardware wallets nor multisig can match at scale.

On the consumer side, things are moving too. Account Abstraction (ERC-4337) is closing some of the UX gaps that multisig never managed to close. Over 40 million smart accounts deployed across Ethereum and Layer 2 networks since March 2023, with nearly 20 million in 2024 alone (Alchemy). Smart wallets are getting genuinely good. The competitive pressure on custody providers is real.

I think we end up with a split world. MPC-TSS for institutions, where the operational overhead is worth it. TEE-based signing for consumer wallets, where experience has to come first. Hybrid architectures are already appearing that combine both layers, hiding the complexity somewhere in the middle.

Then there's the longer question that doesn't come up enough: quantum computing. The elliptic curve cryptography that underpins ECDSA and EdDSA, the signature schemes that Bitcoin and Ethereum run on today, is vulnerable to a sufficiently powerful quantum computer. NIST finalised its first post-quantum signature standards in 2024, including ML-DSA (formerly Dilithium) and SLH-DSA (formerly SPHINCS+). The single-party versions are standardised. The hard part is building threshold versions of these algorithms, applying MPC-TSS logic to post-quantum schemes, and that's still an open research problem. The field is moving: TRaccoon is a recent proposal designed specifically to be threshold-friendly, and NIST's Multi-Party Threshold Cryptography project is working toward standardisation. Until that lands, the near-term answer is probably hybrid signing: a classical key and a post-quantum key both signing every transaction, covering both bases at once.

The thing that stays with me

I spent a lot of time building interfaces for a system whose core property is an absence.

The key doesn't exist. The signing ceremony produces a proof without a secret. The blockchain receives a signature from a key that was never assembled in one place. You build workflows around a concept, distributed trust, that isn't tangible in any normal sense.

And yet it works. Institutions move real money with it every day. The mathematics holds. The system, when implemented correctly, is more secure than almost anything that came before it.

There's something worth sitting with in that. In an industry that often mistakes complexity for security, MPC is a reminder that the most important guarantees are sometimes the hardest to see. Not because they're hidden. Because they were designed so that the dangerous thing, the private key, simply never has to exist at all.

That's not magic. It's applied mathematics.

But from where I was sitting, building the product around it, it felt pretty close.

If you found this useful, I write about TypeScript, crypto infrastructure, and what it's actually like to build in this space. The previous post covered TypeChain and the bridge between Solidity and TypeScript.