Skip to main content

Supported Business Scenarios

To help developers better understand the functionality of SMN suite, we have listed typical business scenarios supported by SMN suite. SMN suite supports, but is not limited to, the following business scenarios:

Keyless Wallet​

With the SMN suite, you can easily build keyless wallets similar to Zengo Wallet or OKX Web3 Wallet.

Application Architecture​

  • Developers integrate SMN suite on the client and server sides.
  • Developers develop their own Apps and backend services, integrating capabilities such as user management, blockchain, and wallet management.

Core Workflow​

Example: 2/2 MPC-TSS Threshold Keyless Wallet

  • Users register or log in to the wallet via email or social login and configure multi-factor authentication (MFA), such as server-side face verification or one-time passwords.
  • The App and developer's server perform MPC Keygen, generating and holding a key share locally. Signing is done using Key Share 1 and Key Share 2.
  • After wallet creation, the developer's server saves an encryption key and sends it to the App. The App uses this key to encrypt Key Share 2 and saves the encrypted data to user-controlled cloud storage such as Google Drive or iCloud.
  • Users log in via email or social login and verify multi-factor authentication (MFA) when they change devices. Upon successful verification, the encryption key is sent to the App. The App retrieves the encrypted Key Share 2 from user's cloud storage, decrypts it to recover Key Share 2, and then deletes the encryption key.

Example: 2/3 MPC-TSS Threshold Keyless Wallet

  • Users register or log in to the wallet via email or social login and configure multi-factor authentication (MFA), such as server-side face verification or one-time passwords.
  • The App and developer's server perform MPC Keygen. The developer's server generates Key Share 1, while the application generates Key Share 2 and Key Share 3. Signing is done using Key Share 1 and Key Share 2.
  • After wallet creation, the developer's server saves an encryption key and sends it to the application. The application uses this key to encrypt Key Share 3 and saves the encrypted data to user-controlled cloud storage such as Google Drive or iCloud. After successful upload, the App deletes Key Share 3.
  • Users log in via email or social login and verify multi-factor authentication (MFA) when they change devices. The encryption key is sent to the App upon successful verification. The App retrieves the encrypted Key Share 3 from the user's cloud storage, decrypts it to recover Key Share 3, and then deletes the encryption key.
  • The App then uses Key Share 3 and the developer's server to execute the MPC Recover protocol to recover Key Share 2. After successful recovery, delete local Key Share 3.

Centralized Asset Management Platform​

With the SMN suite, you can easily build a centralized custody platform, using MPC technology to eliminate the single-point private key risk on the server side and strengthening security through TEE technology.

Application Architecture​

  • Developers choose MPC-TSS thresholds based on their business scenarios, such as using a 2/3 or 3/3 threshold. Developers deploy three smn-service clusters, each representing a participant in MPC and use your own MPC Key Management Service to coordinate the three participants.
  • Developers ensure that the three MPC participants can independently verify the validity of requests through a risk control service, ensuring the secure use of key shares.
  • Developers decide how to manage smn-ca and smn-service clusters according to internal management models, adhering to principles of least privilege and separation of duties.

Core Workflow​

  • The MPC Key Management Service coordinates multiple Co-Signers to complete key share generation, signing, and periodic refreshing.
  • The MPC Key Management Service pre-generates key shares and provides APIs for querying public keys and initiating signing to business parties.
  • Before executing sensitive operations such as requests for signatures, Co-Signers need to request verification from the risk control service to ensure the validity of the request, thus avoiding single-point risks caused by attacks on the MPC Key Management Service.
  • The risk control service should act as a checkpoint in critical business process links and check if there are any preceding dependent business actions.

Self-Custody Platform​

With the SMN suite, you can easily build a self-custody platform similar to Safeheron's self-custody platform, where asset is entirely controlled by customers.

Application Architecture​

  • For example, in a 3/3 threshold scenario, developers manage two cloud Co-Signers, managing two key shares, while the third share is managed by the customer.
  • Developers develop their own Apps and backend services, integrating capabilities such as user management, blockchain, wallet management, transaction engine, and policy engine.

Core Workflow​

Example: 3/3 MPC-TSS Threshold

  • When creating a team, the MPC Keygen protocol is executed to generate three key shares, one each on the two cloud Co-Signers and the creator's device.
  • When adding a member with signing permission, the team creator and cloud Cosigner execute the MPC Refresh protocol to generate three new key shares. The team creator securely transmits a newly generated key share to the new member and then deletes the key share in the creator's App.
  • When sending a transaction, the approval process and the final signer are determined by the client-configured policies in the policy engine. The transaction is then finalized using the MPC Signing protocol by the final signer and the cloud Co-Signer.
Last updated on by xigaoku