Peer-to-Peer Multi-Party Computation — No Server Required
In Device-to-Device MPC, two or more smartphones connect directly to each other (peer-to-peer) to perform threshold signing. No central server is required. The phones discover each other, establish a secure session, and run the MPC protocol locally. Each phone holds one key share and uses its own cryptographic processor to sign.
Transport options: Bluetooth Low Energy (BLE), MultipeerConnectivity (iOS), peer-discovery over local WiFi, or relay servers for out-of-range pairing.
| Transport | Range | Latency | Security |
|---|---|---|---|
| BLE | ~30m | <50ms | Encrypted link layer |
| MultipeerConnectivity (iOS) | WiFi/BLE/P2P | <100ms | TLS + peer cert |
| WiFi Direct (Android) | ~100m | <100ms | WPA2 Enterprise |
| QR + Relay | Internet | 200ms+ | E2E encryption + MAC |
Both phones advertise themselves on the local network using Bonjour (mDNS) or BLE scanning. Each device shows a friendly name and status indicator.
Both users verify that the codes match on both screens (out-of-band). This prevents man-in-the-middle attacks. Once verified, both phones establish a TLS session authenticated by the shared nonces.
Both phones now have a secure, encrypted, and authenticated channel. They can send messages without eavesdropping or tampering.
Round 1 (Commitment): Each phone generates a random key share and a commitment hash. The commitments are exchanged and verified against received messages.
Round 2 (Key Derivation): Both phones derive the same public key Q = (x_0 + x_1)*G and verify it matches.
Round 3 (Storage): Each phone stores its share in the Secure Enclave (iOS) or StrongBox (Android) — a hardware-backed keystore that prevents extraction.
Round 1 (Nonce Generation): Each phone generates a random nonce k_i and broadcasts a commitment to it.
Round 2 (Partial Signatures): Each phone computes a partial signature component and sends it to the other. The partial components are combined.
Round 3 (Final Signature): One phone (designated by access policy) receives the final signature (r, s) and stores it.
Confirm this code appears on both devices:
Generating 256-bit key on secp256k1...
Processing MPC protocol...
| Aspect | Device-to-Device | Server-Based MPC |
|---|---|---|
| Infrastructure | Peer-to-peer (no server) | Client + Server |
| Latency | Low (BLE/WiFi direct) | Higher (network round-trip) |
| Availability | Requires both devices online | Server always available |
| Privacy | No intermediary | Server sees message hashes |
| Scalability | Good for 2-3 parties | Better for N parties |
| Use Case | Peer cosigners, family vaults | Mobile wallet with commitment server |
Best for: Two family members approving transactions together, co-signer scenarios where both parties must physically be present, peer-to-peer commerce apps.
Not ideal for: Large thresholds (3+), always-available signing (if one device is offline, signing fails), enterprise deployments.