Designing 2-of-2 MPC Key Generation for Self-Custody

The security dilemma

In Web3, users historically faced a harsh choice: trust a centralized exchange with their keys (custodial) or write down a 12-word seed phrase on paper (self-custodial). The former exposes users to exchange insolvency; the latter places the entire burden of key security on the user, leading to millions lost to misplaced papers and phishing attacks. Furlpay solves this by implementing 2-of-2 Multi-Party Computation (MPC).

Under the hood: key splitting

With MPC, a single private key is never generated in one place. Instead, during account setup, our backend runs a cryptographic protocol (distributed key generation) to produce two distinct key shares:

• Share A (client-side): stored on the user's device, encrypted and accessible only via WebAuthn / passkey biometrics.
• Share B (server-side): managed inside Furlpay's Hardware Security Module (HSM) cluster, gated by policy rules.

[ Client Device ] ─────> Share A  (biometric-gated)
                            │
                     (co-signing engine)
                            │
[ Furlpay HSM ]   ─────> Share B  (policy rules)

To sign a transaction, the client app and the Furlpay HSM compute a signature cooperatively. Neither party ever reveals its share, and the complete private key is never assembled in memory. If our server is breached, the attacker cannot steal your funds because they lack Share A. If you lose your device, Furlpay assists recovery through a secure social/email verification protocol to regenerate your key shares.

Compromising one share yields nothing usable — an attacker must defeat both the device and the HSM policy at the same time.