Designing 2-of-2 MPC Key Generation for Self-Custody
By Security Engineering · June 28, 2026 · 6 min read
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.
Security Engineering
Furlpay
Written by the Furlpay team — engineers and compliance specialists building an on-chain financial operating system for stablecoin payments, travel, and investing on Arbitrum.
Don't miss the next one
Stay ahead of the curve
Get product updates, engineering deep-dives, and security bulletins. No spam — just the signal.
More in Engineering
Bypassing the 3% Card Tax: How I Built an x402 Settlement Layer for AI Agents and Travelers on Arbitrum
A $340 resort checkout loses $11.90 to five intermediaries before it reaches the hotel — three days later. Here is how I built Furlpay's x402 settlement layer on Arbitrum instead: the actual contract code, measured gas benchmarks from the 34-test suite, the paymaster math behind zero-gas UX, and a direct answer to 'why not just use Stripe?'
July 8, 2026 · 11 min read
Arbitrum vs Base for Payments: Which Layer 2 Should You Settle On?
Both are strong Ethereum Layer 2s with sub-cent fees. For stablecoin payments the deciding factors are settlement finality, ecosystem maturity, and where institutional volume already lives. Here is the honest comparison.
July 6, 2026 · 6 min read
Integrating Furlpay with Arbitrum: Payments, x402 and Contracts on the Largest L2
Furlpay's settlement stack is going Arbitrum-first. Here is exactly what we shipped — an x402 facilitator that settles on Arbitrum, a unified USDC payments API, a chain registry, and four Solidity contracts with a green 17-test suite — and what ships next.
July 5, 2026 · 9 min read