Embedded Wallets
Glossary of Terms
| Term | Definition | Use |
|---|---|---|
| TSS (Threshold Signature Scheme) | A cryptographic protocol that distributes signing authority across multiple parties, requiring a minimum threshold of participants to create valid signatures. Enables secure, distributed control while maintaining resilience against compromise of individual participants. | Dynamic enables the distribution and redistribution of shares across parties. Dynamic allows for thresholds to be adjusted based on the desired level of security and trust. Dynamic’s TSS-MPC infrastructure ensures a private key does not exist or compiled during any signing or ceremonies. |
| TEE (Trusted Execution Environment) | Isolated execution environments running inside hardened Amazon EC2 instances, designed for processing highly sensitive data. Data remains encrypted and is securely handled within the protected environment without exposure. These environments support cryptographic attestation, allowing verification that the enclave is operating correctly and has not been tampered with. Dynamic uses AWS Nitro Enclaves to ensure this level of security. | Protects key management from unauthorized access by using a stateless Trusted Execution Environment (TEE). The TEE is used for encrypting, decrypting, and signing operations involving the server key share. |
| MPC Relay | The infrastructure that manages signing ceremonies and share communication over secure socket connections without ever constructing a full private key. | Enables decentralized signing using key shares, while ensuring secure communication, robust session management, and fault tolerance. |
| Encryption Proxy Service | A relay that securely encrypts and proxies data for backup and recovery. | The encryption proxy service is a third-party encryption service for backups and recovery. It facilitates encrypted backup key storage, recovery, and is used to double encrypt a passcode (if used). |
| Key Resharing | The process of modifying the existing parties or updating the threshold signature scheme (e.g., upgrading from 2-of-2 to 2-of-3). | Used if a user adds a backup or if the Developer would like to modify the signature scheme to host backups for independent recovery. Resharing and refreshing requires user participation to prevent unilateral decisioning. |
| Key Refreshing | The process of replacing existing key shares with new cryptographically equivalent shares, without changing the underlying wallet address. | Improves security by limiting the long-term exposure of key shares. The process can be triggered manually and also runs automatically during resharing. |
| Dynamic Server Share | A key share retained by Dynamic that is generated and encrypted within a Trusted Execution Environment (TEE). | Ensures Dynamic can participate in MPC signing without full key control. |
| User Share | Client-side key share, owned and controlled by the end-user. Depending on the TSS scheme there can be multiple user shares. | Used for signing transactions and stored either locally or with an encrypted backup. Rendered in an iFrame and stored in local storage or in a device enclave when accessed from a mobile device. |
| User Share Backup Options | Methods for securely storing an encrypted copy of the User Share for recovery purposes. Options include Google Drive, Apple iCloud, or local download. The backup is always encrypted before storage, with Dynamic never having access to decryption keys. | Enables User Share recovery in case of device loss or when setting up a new device. When using cloud storage options (Google Drive, Apple iCloud), encryption is done in the browser. For all options, the Encryption Proxy Service ensures Dynamic cannot access the stored share. |
| Passcode Encryption | An optional user-set passcode that encrypts a User Share before storage. | Adds an additional layer of user-controlled security for stored shares and enables share recovery on new devices or sessions. When a passcode is set, a double encryption process is applied: (1) encryption in the browser using the passcode, and (2) encryption by the Proxy Service before storage. Dynamic never sees the passcode and only stores a hash of the encrypted share, ensuring it cannot be used to decrypt the underlying data. |
| Independent Recovery | In 2-of-3 or 3-of-5 configurations, it enables offline recovery without relying on Dynamic. Users can upgrade from a 2-of-2 to a 2-of-3 setup themselves. | Ensures account access if the User Share is lost. Backup shares can be stored by the user on Google Drive, Apple iCloud, or locally. In advanced setups, enterprises can be involved in independent recovery. |
| Developer-Hosted Backups | An enterprise feature allowing organizations to maintain their own backup infrastructure for key shares. | Enables custom backup policies, internal recovery processes, and business continuity management according to organization requirements. |
| ECDSA (DKLs19 Protocol) | A widely used digital signature algorithm for blockchain transactions, implemented using the DKLs19 protocol. | Supported on Ethereum and EVM-compatible chains. Used in Dynamic’s TSS-MPC infrastructure for secure transaction signing. |
| EdDSA (FROST Protocol) | A modern, efficient, and secure digital signature algorithm based on Edwards curves. Implemented using the FROST Protocol. | Supported on Solana, StarkNet, and other ecosystems utilizing EdDSA. Used in Dynamic’s TSS-MPC infrastructure for secure transaction signing. |
| BIP-340 (FROST Protocol) | A Schnorr-based digital signature scheme used in Bitcoin and other networks. Implemented using the FROST Protocol. | Supported on Bitcoin and Taproot-enabled blockchains. Used in Dynamic’s TSS-MPC infrastructure for secure transaction signing. |
Important Note: Dynamic never has access to a quorum of shares that would allow key reconstruction. Even if a backup is encrypted via Dynamic’s Encryption Proxy Service, it cannot be decrypted unilaterally by Dynamic.