Wallet Infrastructure and Security Model
Industry Background
Wallet systems typically depend on one or more foundational cryptographic methods to safeguard private keys. Understanding these approaches provides context for the security model described in this document.
Shamir's Secret Sharing (SSS)
SSS divides a private key into multiple shares, requiring a minimum threshold to reconstruct the original. It provides perfect secrecy — any number of shares below the threshold reveals nothing about the key. SSS is mature, well-tooled, and fast (20–40ms signing). The trade-off is that the private key must be fully reassembled to sign, creating a single point of failure at the moment of reconstitution.
Threshold Signature Schemes (TSS)
TSS (commonly known as MPC) allows multiple parties to jointly produce a signature without ever reassembling the private key. This eliminates the reconstitution risk of SSS. The trade-off is immaturity — the first efficient two-party ECDSA protocol appeared only in 2017 — and performance: each signature involves network roundtrips, introducing latency that can reach several seconds.
Trusted Execution Environments (TEE)
TEEs execute cryptographic operations inside hardware enclaves, ensuring key material is never exposed and only authorized code runs. Clients can verify operations through attestations. TEEs scale well and avoid the roundtrip latency of TSS, but their security depends on enclave integrity, which has historically been vulnerable to side-channel exploits.
WebAuthn PRF Extension
The WebAuthn PRF (Pseudo-Random Function) extension derives a deterministic secret from a user's passkey hardware — Secure Enclave on Apple devices, TPM on Windows, Titan chip on Android. This secret is bound to the device and the user's biometric or PIN, computed on-device during authentication, and never transmitted. It enables a class of wallet designs where key material can be encrypted with a secret that no server has ever seen.
Three-Party Key Protection
Overview
Private keys in this system are never stored whole — not on user devices, not on our servers, not anywhere. Instead, the key material is cryptographically split across three independent parties using a 3-of-3 secret sharing scheme. All three parties must cooperate to reconstruct a key. Fewer than three reveals mathematically zero information about the private key.
This is a hybrid model: it combines passkey-based client-side encryption (PRF-as-KEK), secret sharing, and an isolated server-side enclave into a single architecture. The resulting construction achieves the same information-theoretic security guarantee as Shamir's Secret Sharing — no subset of parties below the threshold gains any information about the key — while binding one share to the user's physical authenticator hardware so that no server-side compromise alone can reconstruct the key.
This is the default security model for all modern devices (all major browsers on iOS, macOS, Android, and Windows).
The Three Parties
Party 1 — The User's Authenticator
The user's passkey hardware computes a deterministic secret bound to that device and the user's biometric or PIN. This output — called a PRF output — is produced on-device during authentication and never transmitted anywhere. It is not stored. It is not logged. It exists only in memory for the duration of the signing operation.
This secret is the user's contribution to key reconstruction. Without it, the other two parties hold nothing that can produce a usable private key.
Party 2 — The API
The API stores an encrypted copy of the user's key material. It is encrypted with the user's PRF-derived secret, which the API has never seen. The API controls access — it will only release this encrypted payload to a request that presents a valid WebAuthn assertion signed by the user's registered passkey. It cannot, however, decrypt the payload itself.
The API acts as an authenticated delivery mechanism, not a key custodian.
Party 3 — The Crypto Enclave
A separate, isolated system — operating independently of the API with its own encryption keys and infrastructure — holds the server-side key share. This share is encrypted at rest with a secret known only to the enclave. The enclave releases the decrypted share only after the request has passed assertion validation, and only to be combined with the user's share in the final signing step.
The enclave never sees the user's PRF output, the user's key share, or the assembled private key.
Security Properties
No Single Point of Failure
| Scenario | Consequence |
|---|---|
| User device stolen | Attacker cannot reproduce the biometric/PIN; PRF output is not obtainable |
| API fully breached | Attacker obtains only ciphertext encrypted with a secret they have never seen |
| Enclave fully breached | Attacker obtains one share of the key; the other share is on neither compromised system |
| API and Enclave both breached | Attacker obtains the encrypted user payload and the server share — but still cannot decrypt the user payload without the PRF output from the physical authenticator |
The last scenario is the critical one. Even a complete compromise of all server-side infrastructure is insufficient to reconstruct a private key. The user's authenticator is the cryptographic gate that no server-side breach can bypass.
Information-Theoretic Security
The hybrid model inherits the same class of security guarantee as Shamir's Secret Sharing: the key split is not merely computationally secure — it is information-theoretically secure. An attacker with unlimited computational power, who holds any two of the three parties' material, gains no information about the private key. There is no algorithm, given any amount of time or hardware, that can derive the key from two parties' data alone. This is the same guarantee provided by a one-time pad.
Non-Custodial by Design
We operate both the API and the enclave. Despite this, we cannot unilaterally access user funds. The user's PRF output is the missing piece — it is produced inside the user's hardware and never transmitted. Our inability to access funds is not a policy or a terms-of-service commitment. It is a mathematical constraint that holds regardless of internal access controls, regulatory pressure, or infrastructure compromise.
How a Transaction Is Signed
All signing happens on the user's device. The private key is never assembled on any server.
- The user approves a transaction in the application. The device authenticates the user via biometric or PIN.
- The device computes its hardware-bound PRF secret locally. This secret never leaves the device.
- The application retrieves the encrypted user payload from the API and the server share from the enclave. Neither of these pieces is usable on its own.
- On the user's device, in memory: the hardware secret decrypts the user payload, yielding the user's key share. The two shares are combined into the full private key.
- The private key signs the transaction — entirely on-device.
- The private key is immediately wiped from memory. It is not cached, not persisted, not logged.
The full private key exists for a matter of milliseconds, only on the user's device, and only during the signing operation. No server ever sees it.
Private Key Export
If a user chooses to export their private key — for example, to migrate to another wallet — the same principle applies. The key is reconstructed and delivered entirely on the user's device. The server provides the encrypted shares, but decryption and assembly happen locally. At no point during export does the private key pass through or become visible to any server.
Passkey Sync and Cross-Device Access
Modern platforms — iCloud Keychain on Apple, Google Password Manager on Android — sync passkeys across a user's devices. The hardware-bound secret used for key reconstruction is part of the synced passkey material, meaning the same PRF output is reproducible on any device in the user's sync group. This preserves the three-party security model across devices: any synced device can participate in signing without any change to the server-side architecture.
Users are informed whether their passkey has been synced to their cloud account, so they always have visibility into the recoverability of their wallet.
PRF support is available on iOS 18+, macOS Sequoia 15.4+, Android 14+, and YubiKey 5 series. For platforms without PRF support, a server-side signing fallback is used.
Comparison to Conventional Wallet Security
| Model | Private key location | Who can access funds |
|---|---|---|
| Standard self-custody (seed phrase) | Stored by user | Anyone with the seed phrase |
| Exchange / hot wallet custody | Stored by operator | Operator (and anyone who compromises operator) |
| Hardware wallet | Stored on device | Anyone with physical device + PIN |
| This system | Never stored whole | Requires user's live authenticator + server infrastructure simultaneously |
Summary
This hybrid model — combining PRF-based client-side encryption, secret sharing, and an isolated enclave — distributes trust across three genuinely independent parties such that no subset of two can reconstruct a private key, with the same information-theoretic security guarantee as Shamir's Secret Sharing. The user's biometric-bound hardware secret is the cryptographic anchor of the entire system. Server-side infrastructure, regardless of how thoroughly it is compromised, cannot produce a valid signature without the user's physical participation.