Wallet-as-a-service architecure and infrastructure security

At their core, wallet systems typically depend on one or more foundational cryptographic methods to safeguard users' private keys: Shamir's Secret Sharing (SSS), Threshold Signature Schemes (TSS), and Passkey-Based Client-Side Signing with PRF-derived key encryption (PRF-as-KEK). These approaches enable applications to carry out essential cryptographic tasks—such as key generation and transaction signing. Each method comes with its own set of trade-offs around security, performance, and custody flexibility, but all of them allow developers to integrate secure key management directly into their applications.

We offer all three approaches—SSS, TSS, and PRF-as-KEK—and combine them to optimize across all trade-offs and deliver best-in-class security and performance. Here's a look at the strengths and limitations of each wallet architecture option:

Shamir's Secret Sharing (SSS) in wallets Shamir's Secret Sharing (SSS) is a well-established cryptographic method that divides a private key into multiple shares, requiring a minimum threshold of shares to reconstruct the original key. This scheme provides perfect secrecy—any number of shares below the threshold reveals absolutely nothing about the underlying key.

The strength of SSS lies in its maturity and proven track record, backed by decades of practical use and robust open-source tooling. It gives developers the flexibility to distribute shares across different systems or custodians, and to rotate or revoke compromised shares without redesigning the overall architecture. Since most operations are performed on the client side, SSS scales efficiently and supports rapid transaction signing—typically completing in 20 to 40 milliseconds with a well-tuned implementation.

That said, SSS does have some drawbacks. Because the private key must be fully reassembled to sign transactions, a single point of failure exists at the moment of reconstitution. Although this risk is confined to individual users rather than the system as a whole, it demands a carefully secured execution environment. SSS also lacks native verifiability—meaning it must be augmented with additional code and processes, since there is no cryptographic mechanism to prove that a key was generated correctly or that shares have been securely destroyed.

Threshold Signature Schemes (TSS) in wallets Threshold Signature Schemes (TSS) (commonly known as MPC) allow multiple parties to jointly generate a cryptographic signature without ever reassembling the private key. This removes the single point of failure present in approaches like SSS, since no individual party ever holds the complete secret. Although TSS can operate across decentralized networks, most wallet implementations use a simpler two-party configuration, where the signing process is divided between the user and the service provider.

The key benefit of TSS is its security model: because the full key is never reconstructed, there is no single point of compromise. It also provides flexibility in how trust is distributed—developers can architect systems spanning multiple parties based on their specific threat model and custody needs.

The main trade-off with TSS is its relative immaturity. The first efficient two-party ECDSA protocol appeared only in 2017, and production-grade libraries are still limited, which makes these systems harder to build, audit, and harden against subtle implementation bugs. Performance is the other consideration: each signature involves one or more network roundtrips between parties, introducing latency that can reach several seconds—an order of magnitude slower than the sub-50ms client-side signing achievable with SSS.

Trusted Execution Environments (TEE) in wallets Trusted Execution Environments (TEEs) execute cryptographic operations inside a secure hardware enclave, ensuring that key shares are never exposed and that only authorized code is permitted to run. Clients can verify that the intended operations were carried out through attestations, which serve as proof that key management was handled securely on the server side.

TEEs provide robust security by relying on hardware-level protections, making them more resilient than purely software-based alternatives. They also scale effectively, delivering lower latency and avoiding the network roundtrips associated with TSS systems. On the other hand, the security of TEEs hinges on the integrity of the enclave, which has historically been susceptible to exploits.

Client-Side Signing with PRF-as-KEK in wallets Client-side signing with PRF-as-KEK is an emerging approach where the private key is generated and used exclusively on the user's device, never touching a server. The WebAuthn PRF (Pseudo-Random Function) extension derives a deterministic encryption key from the user's passkey, which serves as a Key Encryption Key (KEK) to encrypt the private key at rest. The encrypted key can be stored on a server or in cloud storage as an opaque backup blob—neither the server nor the cloud provider can decrypt it without the passkey.

The primary strength of PRF-as-KEK is its non-custodial guarantee through architecture rather than cryptographic protocol complexity. Since the server never holds key material and all signing happens on-device, there is no server-side trust requirement and no single point of compromise on the infrastructure side. This stands in contrast to both SSS and TSS, which rely on server-side operations—SSS requires a secure execution environment to reassemble the key for signing, and TSS requires the server to participate in every signature as an active MPC party. Because the server is a gatekeeper in those models, it can unilaterally enforce policies such as spending limits, address whitelists, and multi-approval workflows—the server simply refuses to sign or participate if a policy is violated. With PRF-as-KEK, the server has no role in signing, so policy enforcement is advisory rather than cryptographically enforced. On the other hand, this also means a server outage has no impact on the user's ability to sign transactions. Performance is excellent—signing completes in under a millisecond with no network roundtrips, compared to 20–40ms for SSS and several seconds for TSS due to its multi-round server communication. Recovery is handled through passkey sync across devices (iCloud Keychain, Google Password Manager): each device's passkey independently encrypts the same private key with its own PRF-derived KEK, so losing one device does not result in key loss as long as another registered device remains available.

The trade-off is that the full private key exists in the client's memory during signing, which means security depends on the integrity of the user's device. A fully compromised device (rooted, with malware that can read process memory) could expose the key—unlike TSS, where even a compromised client cannot sign without server participation. PRF-as-KEK also requires WebAuthn PRF extension support from the authenticator, which as of 2025 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 necessary.

We offer all three approaches and combine them to cover the full spectrum of security and usability requirements:

• PRF-as-KEK (Client-Side Signing) → Default path for consumer self-custody. Non-custodial, zero-latency signing, offline-capable. Best for passkey-native wallets where the user is sovereign.
• SSS (Shamir's Secret Sharing) → Extended backup and recovery. Splits keys into threshold shares for redundancy across custodians or storage locations. Useful when users need recovery options beyond passkey sync.
• TSS (Threshold Signature Schemes) → Maximum security for institutional or high-value use cases. The private key is never reconstructed. Server-side policy enforcement (spending limits, multi-approval workflows) is cryptographically enforced.