A modular SDK built with TSS-Lib and Passkey (FIDO2) authentication, enabling secure, privacy-preserving threshold signing across mobile, web, and hardware environments. 

SDK Overview 

The MPC SDK currently supports Kotlin, Swift, Dart (Flutter), and JavaScript, allowing developers to integrate threshold cryptography seamlessly across mobile apps, browser environments, and firmware. It supports ECDSA (via GG18) and EdDSA (via FROST) signing schemes, built on top of the open-source TSS-Lib. 

The SDK is built to support full t-of-n threshold signing, enabling flexible quorum-based policies across distributed parties. This architecture empowers users with true self-custodial security, where control is distributed without sacrificing usability or performance. Regen Tech's design anticipates increasingly complex key management needs, and the SDK is engineered to meet them head-on. 

Why TSS-Lib? 

TSS-Lib was chosen for its modular, secure, and open-source architecture. It implements distributed key generation and signing protocols that eliminate single points of failure and reduce the attack surface compared to traditional multisig solutions. Because no party ever reconstructs the full private key, and shares remain isolated, the SDK provides enhanced security and forward secrecy. 

FIDO2 Passkey Integration 

To eliminate the need for passwords and seed phrases, the SDK incorporates Passkey authentication using the FIDO2 WebAuthn standard. This enables phishing-resistant, biometric-based login flows that are both user-friendly and cryptographically secure. 

Authentication flow: 

1. User Registration: During onboarding, the SDK triggers device-based key generation. The public key is registered with an authentication server and tied to the user ID and tenant. 

2. Login: During authentication, the device presents the passkey, which is validated via cryptographic challenge by the server. Upon success, a JWT token is issued. 

3. Token Usage: The JWT is used for MPC operations such as key creation, signing, backup, and enforcement of transaction policies. 

With this approach, authentication becomes seamless, private, and immune to phishing attacks, making seed phrase compromises a thing of the past. 

Inside the SDK: A Multi-Device Key Generation Flow 

Here’s a high-level overview of the SDK’s key generation process using a variety of parties: 

• Party A: Mobile  

• Party B: Cloud MPC Server  

• Party C: Hardware signer  

• (Coming soon) Party D: Browser Extension  

These devices collaboratively generate and retain a cryptographic key share. The private key is never constructed in full. 

Steps: 

• Session Initialization: Mobile initializes a session and registers parties. 

• Commitments and Proofs: Each party generates randomness and exchanges zero-knowledge proofs for validation. 

• Encrypted Computation: Secure ECDH-based messaging facilitates computation across gRPC and Bluetooth. 

• Result: Each party stores its share; the derived public key is used across all chains. 

• Backup: Mobile shares are backed up to iCloud or Google Drive; cloud and hardware shards are stored securely. 

• Finalization: The vault is now ready for signing and policy enforcement. 

Imagine a user wants to approve a high-value crypto transaction. They tap to approve on their mobile wallet. Their phone signs using its secure key share, then coordinates with the cloud server and a Bluetooth-connected ActiveCard. A face scan confirms identity via passkey, and the signature completes without ever exposing the full private key. 

Design Principles 

The SDK is designed around four core values: 

• Privacy-preserving: No party ever sees another’s private data. 

• Flexible group configuration: Easily supports dynamic participant groups. 

• Standard compatibility: Works with common blockchain verification. 

• Concurrency: Optimized for fast, multi-threaded execution. 

Its modular structure ensures it can support new platforms, chains, and protocols as the ecosystem evolves. 

Challenges and Lessons Learned 

Building a cryptographic SDK that works seamlessly across mobile, web, and hardware presented notable challenges. Ensuring consistent cryptographic behavior across OS-level APIs required careful abstraction. Bluetooth latency and mobile device limitations had to be mitigated with fallback coordination logic via the cloud. 

User experience was another key focus. Integrating passkey flows without disrupting existing biometric patterns meant working closely with platform-specific authentication layers while maintaining a consistent dev interface. One critical lesson: secure coordination must be invisible to the user. Good MPC isn’t just secure; it’s intuitive. 

Current Status and Roadmap 

Today, the SDK powers our crypto wallet app and supports 2-of-3 signing across Mobile, Cloud, and Active Card parties. It has been deployed in production for demonstrations and partner testing. 

The upcoming roadmap includes: 

• Full t-of-n support for customizable signing thresholds 

• Deeper integration with Account Abstraction (ERC-4337) 

• Additional wrappers and platform targets 

Who It’s For 

he SDK is designed for: 

• Developers building crypto wallets or DeFi tools 

• Identity platforms seeking privacy-preserving key management 

• Partners looking to integrate MPC signing into mobile or browser-based apps 

It provides a flexible, security-hardened foundation for multi-party cryptographic operations, ready to integrate, extend, and scale. 

This article is part of our broader case study on accelerating product readiness for a Silicon Valley security innovator. Read the full case story here.