Robust multi-party computation digital wallet with single-key compatibility

Abstract

A computing system may obtain a mnemonic phrase representing a master crypto-graphic secret. The system may derive, from the mnemonic phrase, one or more hardened private keys corresponding to one or more hierarchical deterministic derivation paths. The system may perform a one-time verifiable secret sharing (VSS) operation to split the mnemonic phrase and the hardened private keys into cryptographic shares. Each cryptographic share may include at least a share of the mnemonic phrase and a share of the hardened private keys. The system may distribute the cryptographic shares to a plurality of computing devices associated with a multi-party computation (MPC) environment. Responsive to distributing, the system may delete a complete version of the mnemonic phrase and the hardened private keys. The system may perform a cryptographic transaction by executing an MPC signing protocol cooperatively using two or more of the plurality of computing devices based on their respective cryptographic shares.

Description

ATTORNEY DOCKET PATENT APPLICATION 088603.01121 of 33Robust Multi-party Computation Digital Wallet with Single-Key CompatibilityTECHNICAL FIELD

[0001] This disclosure generally relates to key generation for cryptocurrency wallets. In particular, the disclosure relates to a technique for secure key generation and enabling compatibility between different cryptocurrency wallets, including single key and multi-party computation (MFC) wallets.BACKGROUND

[0002] Cryptographic wallets are commonly used to manage digital assets on distributed ledger networks (e.g., blockchains) by controlling private cryptographic keys that authorize transactions. Most widely adopted cryptocurrency wallets are so-called single-key wallets, in which a wallet generates or imports a master secret — commonly represented as a mnemonic phrase — and derives one or more private keys using hierarchical deterministic (HD) key derivation standards, such as BIP-32, BIP-39, and BIP-44. These standards allow a single master secret to be deterministically expanded into a hierarchy of keys corresponding to different blockchains, accounts, and addresses, enabling straightforward backup, restoration, import, and export of wallets using a single mnemonic phrase.

[0003] While single-key wallets provide simplicity and interoperability, they suffer from inherent security limitations. Because a single device or environment ultimately possesses sufficient information to reconstruct the private key, compromise of that device — such as through malware, phishing, or unauthorized access — may result in complete loss of control over the associated digital assets.

[0004] To address security concerns associated with single-key wallets, multi-party computation (MPC)-based wallets have been developed in which cryptographic key material is divided into multiple shares and distributed across different devices or entities. In MPC systems, cryptographic operations are performed cooperatively using distributed key shares without reconstructing a complete private key at any single location.

[0005] However, a fundamental incompatibility exists between MPC wallets and standard HD key derivation schemes. In particular, hardened derivation steps used by widely adopted standards require access to private key material, whereas MPC systems are designed to avoid reconstructing private keys for security reasons. As a result, most MPC wallets cannotATTORNEY DOCKET PATENT APPLICATION 088603.01122 of 33natively support standard hardened derivation paths and are generally incompatible with mnemonic-based import and export workflows used by single-key wallets, particularly hardened key derivation steps and mnemonic-based key management. As a result, users are often unable to import or export mnemonic phrases, reuse standard derivation paths, or seamlessly transition between single-key wallets and MPC wallets.

[0006] Accordingly, there exists a need for an improved cryptocurrency wallet architecture and / or technique that provides the security benefits of MPC-based systems while maintaining compatibility with standard single-key wallet workflows, including hierarchical deterministic derivation and mnemonic-based import and export.SUMMARY OF PARTICULAR EMBODIMENTS

[0007] The present disclosure provides a hybrid cryptocurrency wallet architecture and / or technique that combines single-key wallet compatibility with MPC-based security. Stated differently, the present invention provides systems and methods that bridge the longstanding incompatibility between single-key HD wallets — such as those based on BIP-39, BIP-32, and BIP-44 — and MPC wallets, which never reconstruct full private keys for security reasons. The invention introduces a hybrid architecture in which operations that require access to full secret material — such as mnemonic generation, import, and hardened hierarchical key derivation — are performed once during a wallet creation or migration phase, after which sensitive material is distributed using verifiable secret sharing (VSS) and normal wallet operation proceeds using MPC techniques.

[0008] In particular embodiments, a trusted initiating device generates — or imports — a mnemonic phrase and performs all hardened key-derivation steps required by supported blockchains. The resulting hardened-derived private keys, together with the mnemonic phrase itself, are then split into cryptographic shares using VSS and securely distributed to multiple MPC shareholders. Once the shares are distributed, the initiating device deletes all complete secrets, ensuring that no single device retains, reconstructs, or later accesses the full mnemonic or hardened-derived private key material.

[0009] After the VSS-Once process is complete, all subsequent wallet operations — such as non-hardened key derivation and transaction signing — are performed collaboratively using MPC, without ever reconstructing a private key on any device. This architecture preserves the security-in-use guarantees of MPC while enabling full compatibility with mnemonic-based single-key wallets. A user may seamlessly import an existing mnemonic into theATTORNEY DOCKET PATENT APPLICATION 088603.01123 of 33MFC wallet via the one-time hardened-derivation process, or export from the MPC wallet back into a mnemonic by reconstructing the mnemonic shares only under explicit, authorized quorum. The system additionally includes multi-round verification protocols to confirm the correctness of shares and cryptographic parameters, as well as compact backup representations that allow VSS-Once artifacts or share material to be stored efficiently on secure elements, such as smart cards.

[0010] The disclosed invention provides several technical advantages and practical benefits, including, for example and without limitation, (1) Full Mnemonic Compatibility - The system maintains complete compatibility with standard single-key wallets. Users can import and export mnemonic phrases seamlessly, enabling interoperability with single-key wallets and other HD wallets; (2) Security-in-Use and Security-at-Rest - After the VSS-Once step, no device ever reconstructs the private key. All derivations and signing operations are performed through MPC, ensuring robust protection against compromise; (3) One-Time Hardened Derivation Supports All Chains - By deriving hardened paths for all supported blockchains upfront, the system eliminates the need for full key reconstruction later; (4) Robust Integrity and Verification - A multi-round verification protocol ensures that all shareholders receive correct shares and that no malicious or faulty device can inject invalid secrets; (5) Efficient Backup on Constrained Devices - The invention supports compact, metadata-free encoding for backup on smart-card-class secure elements, enabling safe offline recovery options; (6) Non-Custodial by Design - Server shareholders never hold persistent decrypted key shares, reducing legal and regulatory exposure and aligning with user expectations of self-custody; and (7) Easier User Adoption - Because users can continue using mnemonic phrases, switching to MPC wallets becomes frictionless, accelerating consumer adoption of more secure technologies.

[0011] The following numbered examples represent embodiments of the present disclosure.

[0012] Example 1 - A method including, by a computing system: obtaining a mnemonic phrase representing a master cryptographic secret; deriving, from the mnemonic phrase, one or more hardened private keys corresponding to one or more hierarchical deterministic derivation paths; performing a one-time verifiable secret sharing (VSS) operation to split the mnemonic phrase and the one or more hardened private keys into a plurality of cryptographic shares, wherein each cryptographic share includes at least a share of the mnemonic phrase and a share of the one or more hardened private keys; distributing the plurality of cryptographic shares toATTORNEY DOCKET PATENT APPLICATION 088603.01124 of 33a plurality of computing devices associated with a multi-party computation (MPC) environment: responsive to distributing the plurality of cryptographic shares, deleting a complete version of the mnemonic phrase and the one or more hardened private keys such that no single computing device stores a complete private key or complete mnemonic phrase; and performing a cryptographic transaction by executing an MPC signing protocol cooperatively using two or more of the plurality of computing devices based on their respective cryptographic shares.

[0013] Example 2 - The method of Example 1, further including: reconstructing the mnemonic phrase by obtaining cryptographic shares from a threshold number of the plurality of computing devices; and exporting the reconstructed mnemonic phrase to an external singlekey wallet.

[0014] Example 3 - The method of Example 1 , wherein obtaining the mnemonic phrase includes: importing an existing mnemonic phrase from a single-key wallet compliant with a hierarchical deterministic wallet standard.

[0015] Example 4 - The method of Example 1 , wherein obtaining the mnemonic phrase includes: generating the mnemonic phrase in accordance with a hierarchical deterministic wallet standard.

[0016] Example 5 - The method of any one of Examples 1 -4, wherein performing the one-time VSS operation further includes: generating validation data including cryptographic commitments and cryptographic proofs enabling verification of correctness of the cryptographic shares without revealing the mnemonic phrase or the one or more hardened private keys.

[0017] Example 6 - The method of Example 5, further including: performing, based on the validation data, a multi-round verification process prior to activating the cryptographic shares for MPC signing.

[0018] Example 7 - The method of Example 6, wherein the multi-round verification process includes: a first round for commitment and proof distribution; a second round for commitment and parameter verification; a third round for decommitment and consistency verification; and a fourth round for final validation and shares activation.

[0019] Example 8 - The method of any one of Examples 6 to 7, wherein each of the plurality of computing devices stores its respective cryptographic share in a non-activated state until the multi-round verification process is completed.

[0020] Example 9 - The method of any one of Examples 1 to 8, further including: storing at least one cryptographic share as a backup in a secure element.ATTORNEY DOCKET PATENT APPLICATION 088603.01125 of 33

[0021] Example 10 - The method of Example 9, wherein the secure element includes a smart card or hardware-based secure storage device.

[0022] Example 11 - The method of any one of Examples 9 to 10, wherein storing at least one cryptographic share in the secure element includes: applying one or more data compression or storage optimization techniques to reduce or optimize storage size of the at least one cryptographic share such that the at least one cryptographic share is efficiently stored for backup in the secure element.

[0023] Example 1 - The method of any one of Examples 9 to 11, wherein the cryptographic shares are provisioned into the secure element during the one-time VSS operation.

[0024] Example 13 - The method of any one of Examples 1 to 12, wherein each computing device stores its respective cryptographic share in a device-specific secure element.

[0025] Example 14 - The method of any one of Examples 1 to 13, wherein the mnemonic phrase includes a sequence of words encoding an entropy that is used to derive the master cryptographic secret in accordance with a hierarchical deterministic wallet standard.

[0026] Example 15 - The method of any one of Examples 1 to 14, wherein deriving the one or more hardened private keys includes performing one or more hardened derivation operations corresponding to at least one of a purpose level, coin type level, or account level.

[0027] Example 16 - The method of any one of Examples 1 to 15, further including: deriving one or more non-hardened child keys at one or more of the plurality of computing devices using their respective cryptographic shares, wherein the one or more non-hardened child keys are used for address generation and cryptographic transaction signing within the MFC environment.

[0028] Example 17 - The method of any one of Examples 1 to 16, wherein the cryptographic transaction includes broadcasting a signed transaction to a distributed ledger network.

[0029] Example 18 - The method of any one of Examples 1 to 17, wherein the plurality of computing devices associated with the MPC environment includes: a mobile device; a web browser; a cloud service; a hardware device; or a standalone personal computer (PC) application.

[0030] Example 19 - In some aspects, techniques described herein relate to one or more computer-readable non-transitory storage media embodying software that is operable when executed by a computing system to perform the method of any one of Examples 1 to 18.

[0031] Example 20 - In some aspects, the techniques described herein relate to a system including: one or more processors: and one or more computer-readable non-transitory storageATTORNEY DOCKET PATENT APPLICATION 088603.01126 of 33media coupled to the one or more processors and including instructions operable when executed by the one or more processors to cause the system to perform the method of any one of Examples 1 to 18.BRIEF DESCRIPTION OF THE DRAWINGS

[0032] FIG. 1 illustrates an example hierarchical deterministic process for keys generation.

[0033] FIG. 2 illustrates an example key derivation hierarchy including hardened key derivations and non-hardcncd key derivations.

[0034] FIG. 3 illustrates an example MFC signing environment.

[0035] FIG. 4 illustrates an example hybrid cryptographic wallet architecture or technique that combines a one-time verifiable secret sharing (VSS-once) process with an ongoing MFC signing environment, thereby enabling compatibility with single-key hierarchical deterministic wallets while preserving the security benefits of MPC-based transaction execution, according to particular embodiments.

[0036] FIG. 5 illustrates an example multi-round VSS-once initialization and verification workflow for verification of cryptographic shares, according to particular embodiments.

[0037] FIG. 6 illustrates an example method for initializing and operating a cryptographic wallet using a one-time verifiable secret sharing (VSS-once) process in combination with MPC, according to particular embodiments.

[0038] FIG. 7 illustrates an example computer system on which embodiments described herein may be implemented.DESCRIPTION OF EXAMPLE EMBODIMENTS

[0039] Cryptocurrency wallets are software and / or hardware systems that control access to digital assets recorded on one or more distributed ledger networks (e.g., blockchains) by generating, storing, and using cryptographic key material. Rather than storing digital assets directly, such wallets manage private keys that authorize cryptographic transactions on corresponding blockchain networks. Most of the current cryptocurrency wallets are single-key hierarchical deterministic (HD) wallets that generate key(s) from a bitcoin improvement proposal (BIP) BIP-39 mnemonic through a hierarchical deterministic process. These single key wallets are typically based on BIP-32 and / or BIP-39 standards, where private keys are derived from a master key. In general, most single key wallets use a hierarchical deterministicATTORNEY DOCKET PATENT APPLICATION 088603.01127 of 33key derivation process for key generation or derivation. The main objective of this key derivation is to generate a secret only once and derive all necessary private keys from that secret (e.g., mnemonic word). This approach eliminates the need to create a separate secret for each coin and simplifies the process of making a backup, importing, and exporting the secret.

[0040] FIG. 1 illustrates an example hierarchical deterministic process 100 for keys generation. The process 100 is consistent with widely adopted standards such as BIP-32 and BIP-39. As shown, the process 100 begins with an entropy source 102, which generates a sequence of random binary numbers or pseudo-random bits (e.g., 128 to 256 bits) suitable for cryptographic use. The raw binary numbers or pseudo-random bits are hard to remember. As such, this entropy is encoded into a mnemonic phrase or mnemonic words 104, typically including a human-readable sequence of words selected from a predefined word list. By way of an example and without limitation, the mnemonic phrase 104 may include a twelve -word sequence such as “gravity machine north sort system female filter attitude volume fold club stay,”. As another example, the mnemonic words may include words like “holiday, monitor, mango, mail, example, puppy, deposit, card, repeat, end, close, dawn,”. It should be understood that the specific words, length, and language of the mnemonic phrase are exemplary only. The mnemonic phrase 104 may serve as a compact and user-friendly representation of the underlying entropy and enables reliable backup and recovery of the wallet.

[0041] The mnemonic phrase 104 may be processed to derive a root seed 106, which in turn may be used to generate a master key 108, such as a master private key and associated chain code. From the master key 108, the process 100 deterministically derives a plurality of child keys HOa-llOn, each of which may correspond to a private key associated with a particular blockchain, account, or address. In many implementations, each child private key 110a-l lOn further enables the derivation of corresponding grandchild keys 112a-l 12n, such as public keys or address keys used for receiving funds or verifying transactions.

[0042] As discussed elsewhere herein, a single master key or secret can be used to generate all keys in the hierarchy. The key derivation process in a single key wallet may involve both hardened and non-hardened derivations. FIG. 2 illustrates an example key derivation hierarchy 200 including hardened key derivations 210 and non-hardened key derivations 220, as commonly defined in BIP-32-based wallet standards. Specifically, the key derivation hierarchy 200 expands upon the hierarchical deterministic wallet architecture of FIG. 1 by showing how cryptographic keys are derived using a combination of hardened derivation steps 210 and non-hardened derivation steps 220. The illustrated hierarchy originates from the masterATTORNEY DOCKET PATENT APPLICATION 088603.01128 of 33key 108, which is itself derived from the root seed 106 and mnemonic phrase 104, as previously described. As used herein, a derivation path may be expressed using a sequence of indices separated by slashes (e.g., m / 44707070 / 5). An index followed by an apostrophe (') denotes a hardened derivation, while an index without an apostrophe denotes a non-hardened derivation. Hardened key derivations 210 and non-hardened derivations 220 differ in both cryptographic construction and security properties, as explained below.

[0043] The derivation hierarchy begins at the master key 108, denoted as m. The master key represents the root private key from which all descendant keys in the hierarchy are deterministically derived. Access to the master key 108 enables derivation of all hardened and non-hardened child keys beneath it. At the first hierarchical level (e.g., Level 1), a hardened derivation step 212 is performed to derive a purpose key, such as m744'. In this example, the index 44 'corresponds to a wallet standard identifier defined by BIP-44. Because this derivation is hardened (as indicated by the apostrophe), the child key m / 44' can only be derived using the parent private key and cannot be derived from the parent public key. This hardened derivation ensures that compromise of a descendant key docs not enable reconstruction of higher-level keys in the hierarchy.

[0044] From the purpose key m / 44 a second hardened derivation step 214 is performed at a second hierarchical level (e.g., Level 2) to derive a coin-type-specific key, such as m / 4470' or m / 44760'. The coin type index identifies a particular blockchain network. For example: O' may correspond to Bitcoin, 60 ' may correspond to Ethereum. Thus, m / 44760' represents a hardened private key associated with the Ethereum blockchain under the BIP-44 standard. AsATTORNEY DOCKET PATENT APPLICATION 088603.01129 of 33with the previous level, this derivation is hardened and requires access to the parent private key.

[0045] At the third hierarchical level (e.g., Level 3), another hardened derivation step 216 is used to derive an account-specific key, such as m / 4476070' . The account index allows a user to logically separate assets into multiple accounts (e.g., personal account, business account) under the same coin type. The use of hardened derivation at the account level further isolates accounts from one another, such that compromise of a key in one account does not affect other accounts in the hierarchy.

[0046] After completion of the hardened derivation levels, the hierarchy transitions to non-hardened derivations 220. At the fourth hierarchical level (e.g., Level 4), a non-hardened key 222 is derived, such as m / 447607070. In this context, the index 0 may correspond to an external (receiving) address chain, while an index of J may correspond to an internal (change) address chain. Because this derivation is non-hardened (no apostrophe), the child public key for this level can be derived from the parent public key without revealing the parent private key. This property enables address generation in environments that do not have access to private key material.

[0047] At the fifth hierarchical level (e.g., Level 5), additional non-hardened derivation steps are performed to derive individual address keys, such as in / 447607070 / 5, shown as nonhardened key 224. The final index (e.g., 5) identifies a specific address within the address chain. For example, the derivation path m / 447607070 / 5 corresponds to the sixth externally usable Ethereum address under account zero. Each increment of the final index produces a distinct private / public key pair, allowing a wallet to generate an arbitrary number of addresses without reusing keys.

[0048] The mixed hardened and non-hardened derivation structure illustrated in FIG. 2 provides important security and usability benefits for single-key hierarchical deterministic wallets. However, because hardened derivation steps 212-216 inherently require access to a complete private key, this structure is fundamentally incompatible with many practical MPC systems, in which private keys are never reconstructed in a single location. MPC wallets do not involve hardened key derivation, and private keys are not reconstructed for security reasons. While a traditional garbled circuit approach could be used to derive the key without revealing the private key, this method is very slow and limited to 2-of-2 configurations, making it impractical. As a result, MPC wallets are not fully compatible with single key wallets, such asATTORNEY DOCKET PATENT APPLICATION 088603.011210 of 33BIP32 / 39-based wallets. Not fully compatible means that MPC wallets cannot use the same master key (share) as BIP32 / 39 to derive the same child keys.

[0049] FIG. 3 illustrates an example MPC signing environment 300 in which cryptographic key material is distributed across multiple participants in the form of key shares 302a-302e. In this configuration, a private key is never assembled in its entirety at any single device. Instead, each participant holds a partial share (e.g., ksl, ks2, ks3) of the underlying secret, and cryptographic operations are performed cooperatively. A message 306 to be cryptographically signed is provided as input to an MPC signing function 304, which cooperatively processes the message using a subset or all of the key shares 302a-302e without reconstructing the complete private key at any single device. The MPC signing function 304 produces a cryptographic signature corresponding to the underlying private key. The resulting signature may be verified using a corresponding public key 312 through a signature validation process 310, which confirms that the signature was generated by possession of the correct underlying private key material without revealing any individual key share. A relying party 308 may use the signature validation process to authenticate the message or authorize a cryptographic transaction.

[0050] In this manner, the MPC signing environment 300 provides enhanced security by ensuring that compromise of any single key share 302a-302e does not enable unauthorized signing or reconstruction of the private key. The MPC only has private key shares. Hence, any key derivation that involves a private key is not compatible with MPC. For example, taking the same m / 44707070 / 5 example as discussed above, MPC cannot produce 447070’ (’ denoting hardened key derivation). BIP-44 and similar standards use hardened derivation for the first 3-4 levels and normal derivation for the remaining 2-3 levels. For example, BIP-44 specifies a 5-level depth derivation from the master key (m / 44707070 / x, where ' denotes hardened derivation and x is a child key index). Therefore, addresses (e.g., keys) typically cannot be ported between single key wallet (involving both the hardened and normal key derivations) and MPC wallet (involving just the normal key derivations). Individual private keys can be imported from a single key wallet into an MPC Wallet, and sharded. However, the MPC wallet would then not be able to derive other private keys in the hierarchy, severely limiting the usefulness of this approach. This may limit user adoption.

[0051] For traditional single key wallet holder (e.g., BIP32 / 39 wallet holders) to adopt MPC wallets, they would either need to import / expoit all private keys or make an on-chain transaction for each asset they hold. Additionally, MPC operations, such as creating MPCATTORNEY DOCKET PATENT APPLICATION 088603.011211 of 33shares, take a non-negligible amount of time (10-30 seconds), and signature computation also takes significantly longer than in BIP32 / 39 wallets. This limits the application of MFC in automated trades, such as arbitrage bots, which require real-time signature computation. Furthermore, there is a direct trade-off between security and user experience. For example, if an MPC setup involves three or more shareholders, the user must handle all devices simultaneously, complicating the process.

[0052] Two approaches for key generation and signing may be used. However, each approach has its own advantages and disadvantages. The first approach is a verifiable secret sharing (VSS) always approach. In VSS always, one entity generates a full master private key (or mnemonic phrases), splits it into multiple shards, and distributes these shards to other parties. During the signature process, the shards are sent to a single entity (e.g., a mobile phone or cloud service, depending on the configuration), and a signature is created. This system essentially provides security at rest but not security in-use (e.g., if the signing device is compromised during the signing process, a hacker could access the complete private key and assets could be lost). Since a private key is fully reconstructed in-use, VSS is not truly an MPC approach.

[0053] The second approach is the MPC in which a key is created through a distributed key generation (DKG) process (e.g., Feldman's DKG), as shown and discussed in reference to FIG. 3. The private key is never constructed during the signature computation, which aims to provide both security at rest and, to a varying degree depending on the configuration, security in-use. MPC wallets typically generate VSS shares of a private key through a collaborative calculation. The private key never exists in one place, neither during generation nor signing. Although secure, it has the inherent limitations as discussed above. Virtually all MPC wallets in the market today are not compatible with a single key wallet. Users cannot convert between a single key and MPC wallets.

[0054] Accordingly, there exists a need for a cryptographic wallet architecture that preserves the usability and interoperability advantages of single-key hierarchical deterministic wallets while simultaneously providing the enhanced security properties of MPC-based systems. As described in detail with reference to FIG. 4, the present disclosure addresses this need by introducing a hybrid architecture or technique in which a one-time verifiable secret sharing (VSS-once) process performs required hardened derivations and mnemonic handling in a controlled initialization phase, after which cryptographic secrets are distributed across MPC shareholder devices for ongoing MPC-based transaction execution.ATTORNEY DOCKET PATENT APPLICATION 088603.011212 of 33

[0055] FIG. 4 illustrates an example hybrid cryptographic wallet architecture or technique 400 that combines a one-time verifiable secret sharing (VSS-once) process with an ongoing MPC signing environment, thereby enabling compatibility with single-key hierarchical deterministic wallets while preserving the security benefits of MPC-based transaction execution. As shown, FIG. 4 integrates mnemonic-based key generation and hardened derivation operations with distributed key sharing, verification, and MPC signing, without requiring persistent storage or reconstruction of complete private keys at any single device. The architecture or technique 400 discussed herein provides a good balance between security, user adoption, and compatibility between the different wallets, including compatibility between a single key wallet and an MPC wallet.

[0056] As shown on the left side of FIG. 4, the technique 400 may interoperate with an external single-key wallet 402, which may be compliant with hierarchical deterministic wallet standards such as BIP-39 and BIP-44. The single-key wallet 402 may provide a mnemonic phrase 404 that is imported into the system, or may receive a reconstructed mnemonic phrase exported from the system, as described further below. In this manner, the architecture / technique 400 supports bidirectional interoperability between single-key wallets and MPC-based wallets.

[0057] The architecture 400 includes an initiating device 410, which may be a user-controlled computing device such as a mobile device, laptop, or other trusted endpoint. The initiating device 410 may be responsible for performing the one-time VSS-once initialization operations. In particular, the initiating device 410 may generate or receive a mnemonic phrase 412, either by generating the mnemonic phrase locally or by importing the mnemonic phrase from the single-key wallet 402 via the import operation 404. Using the mnemonic phrase 412, the initiating device 410 may perform hardened key derivations 414, such as those illustrated and described with respect to FIG. 2, to derive one or more hardened-derived private keys corresponding to supported blockchain networks, accounts, or derivation paths. For instance, the initiating device 410 derives the target private keys for different assets, cryptocurrcncics, and / or coins (e.g., BTC, Ethereum, Solana). As an example, when a user first creates a wallet (e.g., MPC wallet), then the initiating device 410 (e.g., mobile device) may generate the mnemonic words and derive the target private keys for the different assets (e.g., BTC, Ethereum, Solana). The initiating device 410 further generates verification data 416, which may include cryptographic commitments, proofs, or other verification material configured toATTORNEY DOCKET PATENT APPLICATION 088603.011213 of 33enable recipients to verify correctness of distributed shares without revealing the underlying mnemonic phrase or hardened-derived private keys.

[0058] Following generation of the mnemonic phrase 412, hardened-derived private keys 414, and verification data 416, the initiating device 410 may perform a one-time verifiable secret sharing (VSS) operation, producing a plurality of cryptographic shares 418a, 418b, ..., 418n. Each cryptographic share may include, for example, (i) a share of the mnemonic phrase and (ii) a share of one or more hardened-derived private keys. These cryptographic shares along with corresponding verification data 416 may be distributed to a plurality of MPC shareholder devices 420a-420n (individually and / or collectively referred to as 420) associated with a MPC signing environment, such as the MPC signing environment 300.

[0059] The MPC shareholder devices 420 may include heterogeneous devices such as a phone 420a, a browser-based device 420b, and a cloud-based device 420n. After distribution of the cryptographic shares, the initiating device 410 deletes any complete version of the mnemonic phrase and hardened-derived private keys, such that no single device retains full key material. Therefore, even if the initiating device 410 is hacked, no one would be able to access or reconstruct the private key and / or access the wallet address. Doing so ensures both security at rest and the security-in-use. Compared to the VSS-always technique, where a private key can be reconstructed during signing, in the hybrid technique 400 discussed herein, a private key is created only once during the initial wallet creation and / or key generation phase and is deleted once shards / shares of that private key are sent to the shareholders. In some embodiments, the initiating device 410 may keep a cryptographic share for itself.

[0060] By way of an example and without limitation, a key generation example in an MPC system with mobile application, browser extension application, and cloud would be as follows:• Mobile creates mnemonic words (or random number)• Mobile derives keys for BTC, ETH, Solana, ...• Mobile splits the keys and the mnemonic words• Mobile sends a shard of each key and the mnemonic words to the browser and the cloud • Mobile deletes the shards that are sent to the browser and the cloud

[0061] Each MPC shareholder device 420a-420n stores its received cryptographic share and participates in a multi-round verification process 422 in communication and / or cooperation with the initiating device 410. Based on the verification data 416, the multi-roundATTORNEY DOCKET PATENT APPLICATION 088603.011214 of 33verification process 422 may ensure that all cryptographic shares were correctly generated and distributed before being activated for use in the MFC environment. In the illustrated embodiment, the multi-round verification process includes rounds 1-4, as shown and discussed in FIG. 5. These rounds 1-4 may involve, at a high level: (1) verification of cryptographic commitments associated with the shares, (2) verification of cryptographic proofs attesting to correctness of share generation, (3) decommitment and consistency checks, and (4) final validation and acceptance of the cryptographic shares for MPC use. The specific operations, messages, and cryptographic proofs exchanged during rounds 1-4 are described in further detail with reference to FIG. 5.

[0062] Once verification is complete, each MPC shareholder device 420 may perform non-hardened key derivations 424 locally, using its share of the hardened-derived private keys, without reconstructing any complete private key. These non-hardened derivations may enable generation of child keys used for address derivation and transaction signing, consistent with hierarchical deterministic wallet standards.

[0063] As further shown in FIG. 4, one or more cryptographic shares generated during the VSS-once process may be stored using a secure element backup 426. The secure element backup 426 may provide tamper-resistant, hardware-protected storage for sensitive cryptographic material while preserving the distributed security properties of the MPC environment. In some embodiments, the secure element backup 426 may include a hardwarebased secure storage device, such as a smart card, embedded secure element, trusted platform module (TPM), secure enclave, or other hardware security module configured to prevent unauthorized extraction of stored data. The secure element backup 426 may be physically separate from the MPC shareholder devices or may be integrated into one or more MPC shareholder devices 420, such as a mobile device, browser extension environment, or dedicated hardware wallet. The secure element backup 426 may store only partial cryptographic material, such that no complete mnemonic phrase or private key is reconstructable from the secure clement alone. The stored data remains usable only in cooperation with other MPC shareholder devices in accordance with threshold or authorization policies.

[0064] To enable efficient storage of cryptographic shares within constrained secure element memory, the system may apply one or more data compression or storage optimization techniques prior to storing data in the secure element backup 426. In some embodiments, such optimization techniques may include, for example and without limitation, (1) share compression, in which cryptographic shares may be represented using a reduced-size encodingATTORNEY DOCKET PATENT APPLICATION 088603.011215 of 33or compressed numeric form while preserving correctness for MFC operation; (2) metadata omission, in which descriptive labels, headers, or redundant structural information may be removed and reconstructed dynamically during use; (3) positional or rule-based encoding, in which the meaning or role of a stored share may be inferred based on its storage position, index, or pre-defined interpretation rules rather than explicit tagging; and (4) deterministic rederivation, in which only a minimal subset of data required to regenerate a cryptographic share is stored, while other components are deterministically recomputed when needed. These techniques reduce storage footprint while maintaining cryptographic integrity and compatibility with the MPC signing and verification workflows.

[0065] In particular embodiments, the secure element backup 426 may include a smart card, which may be issued to a user or custodian and configured to securely store one or more cryptographic shares. The smart card may include an embedded secure processor and isolated memory region that enforces access control, cryptographic operations, and anti -tampering protections. In such embodiments, the smart card does not expose stored cryptographic shares in plaintext form. Instead, the smart card may participate in MPC signing or reconstruction protocols by performing limited cryptographic operations internally and returning intermediate results, without revealing the underlying share. This enables the smart card to function as an additional MPC participant or recovery component while maintaining strong security guarantees.

[0066] In some embodiments, cryptographic shares may be pre-provisioned and stored upfront in a secure element during VSS-once initialization for backup and recovery purposes. For example, the initiating device 410 may provision one or more secure elements with optimized cryptographic shares at setup time. In other embodiments, each MPC shareholder device 420 may store its own share within a device- or user- level secure element, enabling the secure element to participate directly in MPC signing while maintaining distributed trust. For example, each MPC shareholder device 420a-420n stores its respective cryptographic share within a local secure clement.

[0067] Once one or more of the multi-round verification 422, non-hardened key derivations 424, or the secure element backup 426 operations are completed, normal MPC operations may follow. During normal MPC operations, the MPC shareholder devices 420a-420n may cooperatively participate in generating transaction signatures 430 using MPC signing protocols. The MPC signing protocols operate on distributed cryptographic shares and derived keys, ensuring that no complete private key is reconstructed during the signing process.ATTORNEY DOCKET PATENT APPLICATION 088603.011216 of 33Upon generation of a valid transaction signature, the system may perform a cryptographic transaction 440, such as broadcasting a signed blockchain transaction to a distributed ledger network.

[0068] In some embodiments, the system may support reconstruction of the mnemonic phrase under controlled conditions. As shown, a mnemonic reconstruction process 450 may be initiated, for example, in response to a user request or authorization policy. During reconstruction, a threshold number of MPC shareholder devices 420 provide their respective mnemonic shares, allowing the mnemonic phrase to be temporarily reconstructed. The reconstructed mnemonic phrase may be exported 452 to the single-key wallet 402 or another external wallet system. After export, the reconstructed mnemonic phrase is not persistently stored by the MPC system.

[0069] In the hybrid technique 400 discussed herein, the characteristics of single key and MPC wallets are mixed to give the benefit of MPC while retaining single key address compatibility. Porting or transferring an asset from a single key wallet to an MPC wallet or vice versa may be made simply using mnemonic words. For example, one party may import a mnemonic word from the single key wallet. Using the imported mnemonic word, that party may derive the target private keys (e.g., using hardened and non-hardened key derivations) and then send shards of the private keys and the mnemonic words to other parties or shareholders in the MPC for the signing, as discussed above. Alternatively, if one wants to port from the MPC wallet to a single key wallet, then a user may command all MPC shareholders to do so by jointly reconstructing a mnemonic phrase / word using their respective mnemonic word shares and exporting the reconstructed mnemonic word to the desired single key wallet, which may then use that reconstructed mnemonic word to derive the private keys and generate the full wallet address.

[0070] In this manner, FIG. 4 illustrates a hybrid cryptographic wallet architecture or technique that combines the interoperability and usability advantages of mnemonic-based single-key wallets with the enhanced security of MPC-bascd signing. The VSS-oncc approach enables hardened derivation steps to be performed in a controlled initialization phase while enabling ongoing non-hardened derivation and transaction execution using MPC, thereby overcoming the incompatibilities described with respect to FIGS. 1-3. One can think of this hybrid technique as a technique that sits in between the VSS always and MPC and therefore aims to provide both the security at rest and the security-in-use. The hybrid technique 400 uses VSS during the initial key generation and MPC during signature computation. It resolves theATTORNEY DOCKET PATENT APPLICATION 088603.011217 of 33compatibility issue while providing a good balance between security and business (e.g., user adoption).

[0071] Below is a table summarizing and comparing the VSS-always, VSS-once, and full MPC approaches and associated advantages, disadvantages, and security with each approach.

[0072] FIG. 5 illustrates an example multi-round VSS-once initialization and verification workflow 500 for verification of cryptographic shares. As depicted, the workflowATTORNEY DOCKET PATENT APPLICATION 088603.011218 of 33500 may be executed between an initiating device 410 and one or more MFC shareholder devices 420. The workflow 500 is divided into four sequential verification rounds (Rounds 1-4), each of which performs a distinct class of cryptographic operations to ensure that a mnemonic phrase and hardened-derived private keys are correctly generated, verifiably shared, validated, and safely transitioned into an active multi-party computation (MFC) environment. At a high level, round 1 (steps 502-514) performs key generation and initial verifiable secret sharing, round 2 (steps 516-524) validates commitments, proofs, and cryptographic parameters, round 3 (steps 526-540) performs decommitment and consistency verification, and round 4 (steps 542-554) finalizes validation, activates the shares for MPC use, and deletes residual complete key material. This staged, multi-round structure ensures cryptographic correctness, prevents malformed or adversarial shares from being activated, and guarantees that no complete mnemonic phrase or private key persists outside the MPC environment. The individual steps associated with each round are described in detail below.

[0073] Referring to round 1, at step 502, the initiating device 410 may generate a mnemonic phrase or import an existing mnemonic phrase. The mnemonic phrase may be generated locally using cryptographic entropy or received from a single-key wallet. At step 504, the initiating device 410 may derive one or more hardened private keys from the mnemonic phrase in accordance with hierarchical deterministic wallet standards, such as BIP-32 or BIP-44. At step 506, the initiating device 410 may generate verifiable secret sharing (VSS) shares of both the mnemonic phrase and the hardened-derived private keys. Each share represents a partial cryptographic representation of the underlying secrets. At step 508, the initiating device 410 may generate commitment data corresponding to the VSS shares, such as commitments that bind each share to an underlying secret polynomial without revealing the secret. At step 510, the initiating device 410 may generate initial cryptographic proofs, such as zero-knowledge proofs, attesting that the VSS shares were correctly generated and are consistent with the committed secrets. At step 512, the initiating device may send the VSS shares (including shares of the mnemonic phrase and hardened-derived private keys) and validation data (e.g., the commitment data, and the cryptographic proofs) to each of the MPC shareholder devices 420. At step 514, each MPC shareholder device 420 may store the received data in a non-activated or provisioned state, such that the shares are not yet usable for MPC signing.

[0074] Referring to round 2, at step 516, the MPC shareholder device 420 may verify the commitment data by checking that the received VSS shares correspond to the previouslyATTORNEY DOCKET PATENT APPLICATION 088603.011219 of 33generated commitments. At step 518, the MPC shareholder device 420 may verify the initial cryptographic proofs to confirm that the VSS shares were generated correctly and in compliance with the VSS scheme. At step 520, the MPC shareholder device 420 may validate cryptographic parameters associated with the VSS scheme, such as threshold parameters, group parameters, or MPC security constraints. At step 522, the MPC shareholder device 420 may generate additional cryptographic proofs, such as proofs related to small-factor correctness or modulus properties, to further validate cryptographic soundness. At step 524, the MPC shareholder device 420 may send verification results, parameter validation responses, and the additional cryptographic proofs back to the initiating device.

[0075] Referring to round 3, at step 526, the initiating device 410 may verify the additional cryptographic proofs received from the MPC shareholder device 420. At step 528, the initiating device 410 may generate decommitment data corresponding to the previously sent commitments, enabling verification of consistency between commitments and the underlying VSS shares. At step 530, the initiating device 410 may generate public consistency data, such as public keys derived from the hardened-derived private keys, to enable crosschecking of share correctness. At step 532, the initiating device 410 may send the decommitment data and public consistency data to the MPC shareholder device 420. At step 534, the MPC shareholder device 420 may verify consistency between the earlier commitments and the VSS shares using the decommitment data. At step 536, the MPC shareholder device 420 may verify consistency between the public keys and the VSS shares using the public consistency data. At step 538, the MPC shareholder device 420 may generate additional cryptographic proofs, such as further zero-knowledge proofs or Schnorr proofs, indicating successful or unsuccessful consistency verification. At step 540, the MPC shareholder device 420 may send the consistency verification results and additional cryptographic proofs to the initiating device 410.

[0076] Referring to round 4, at step 542, the initiating device 410 may perform a final validation to confirm that all prior verification rounds have completed successfully. At step 544, each of the MPC shareholder devices 420 may independently perform a corresponding final validation to confirm that all verification requirements have been satisfied. At step 546, upon successful validation, the MPC shareholder device 420 may transition the VSS shares from the non-active or provisioned state to an active state, thereby marking the shares as usable for MPC signing operations. At step 548, the MPC shareholder devices may send share acceptance or activation confirmation to the initiating device 410, indicating that the VSSATTORNEY DOCKET PATENT APPLICATION 088603.011220 of 33shares have been accepted and activated. At step 550, the initiating device 410 may finalize the setup process for the MFC environment. At step 552, the initiating device 410 may delete the complete mnemonic phrase, ensuring that no full mnemonic remains stored at the initiating device. At step 554, the initiating device 410 may delete all hardened-derived private keys, thereby ensuring that no complete private key material remains outside the distributed MPC environment.

[0077] In this manner, the multi-round workflow illustrated in FIG. 5 ensures that mnemonic phrases and hardened-derived private keys are generated, shared, verified, and activated in a verifiable, auditable, and cryptographically sound manner, while preventing persistent storage or reconstruction of complete private key material at any single device. This workflow enables secure transition from single-key wallet compatibility to MPC-based signing.

[0078] FIG. 6 illustrates an example method 600 for initializing and operating a cryptographic wallet using a one-time VSS-once process in combination with MPC. The method 600 enables compatibility with mnemonic-based single-key wallets while ensuring that no complete private key or mnemonic phrase is persistently stored at any single computing device during or after initialization.

[0079] At step 610, the method 600 may include obtaining a mnemonic phrase representing a master cryptographic secret. The mnemonic phrase may be generated using cryptographically secure entropy and encoded into a sequence of human-readable words in accordance with hierarchical deterministic wallet standards (e.g., BIP-39). In some embodiments, the mnemonic phrase may be newly generated, while in other embodiments the mnemonic phrase may be imported from an external single-key wallet. The mnemonic phrase may serve as the root secret from which subsequent private keys are deterministically derived.

[0080] At step 620, the method 600 may include deriving, from the mnemonic phrase, one or more hardened private keys corresponding to different blockchain networks. The hardened private keys may be derived by performing one or more hardened hierarchical deterministic derivation operations, such as hardened derivations at purpose, coin-type, or account levels. Each hardened private key may correspond to a specific blockchain (e.g., Bitcoin, Ethereum, Solana), account, or derivation path, and hardened derivation ensures cryptographic isolation between branches of the key hierarchy.

[0081] At step 630, the method 600 may include performing a one-time verifiable secret sharing (VSS) operation to split both the mnemonic phrase and the one or moreATTORNEY DOCKET PATENT APPLICATION 088603.011221 of 33hardened-derived private keys into a plurality of cryptographic shares. Each cryptographic share may include (1) a share of the mnemonic phrase and (2) a share of the one or more hardened-derived private keys. The VSS operation may further generate validation data including, for example and without limitation, cryptographic commitments and proofs that enable recipients to verify correctness of the shares without revealing the underlying secrets.

[0082] At step 640, the method 600 may include distributing the plurality of cryptographic shares to a plurality of computing devices (e.g., MPC shareholder devices 420). These computing devices may include, for example and without limitation, a mobile device, a web browser, a cloud server, a hardware device, or a standalone PC application, allowing users to use PC-based programs if needed. The plurality of computing devices may be associated with an MPC environment, such as the MPC signing environment 300. Each computing device may receive a respective cryptographic share and may store the share locally, such as within secure memory or a secure element (e.g., smartcard). No single computing device receives sufficient information to reconstruct the complete mnemonic phrase or any complete private key.

[0083] At step 650, the method 600 may include, in response to distribution of the plurality of cryptographic shares, deleting a complete version of the mnemonic phrase and the one or more hardened-derived private keys. This deletion ensures that no complete private key or mnemonic phrase remains stored at any single computing device, including the device that initially generated or imported the mnemonic phrase. As a result, the master cryptographic secrets exist only in distributed form across the MPC environment.

[0084] At step 660, the method 600 may include performing a cryptographic transaction by executing an MPC signing protocol cooperatively by two or more of the plurality of computing devices. Each participating computing device may contribute its respective cryptographic share of the mnemonic phrase and the one or more hardened-derived private keys to the MPC signing protocol. The MPC signing protocol may generate a valid cryptographic signature without reconstructing the complete private key at any single computing device, thereby enabling secure transaction execution while preserving distributed control and enhanced security.

[0085] The method 600 of FIG. 6 provides a secure and interoperable approach for transitioning from mnemonic-based key generation to MPC-based transaction execution. By combining hardened key derivation, one-time verifiable secret sharing, distributed storage, andATTORNEY DOCKET PATENT APPLICATION 088603.011222 of 33MFC signing, the method 600 prevents persistent exposure of complete private keys while maintaining compatibility with hierarchical deterministic wallet standards.

[0086] Particular embodiments may repeat one or more steps of the method of FIG. 6, where appropriate. Although this disclosure describes and illustrates particular steps of the method of FIG. 6 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of FIG. 6 occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example method for initializing and operating a cryptographic wallet using a one-time VSS-once process in combination with MFC, including the particular steps of the method of FIG. 6, this disclosure contemplates any suitable method for initializing and operating a cryptographic wallet using a one-time VSS-once process in combination with MPG, including any suitable steps, which may include a subset of the steps of the method of FIG. 6, where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the method of FIG. 6, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the method of FIG. 6.

[0087] FIG. 7 illustrates an example computer system 700. In particular embodiments, one or more computer systems 700 perform one or more steps of one or more processes, algorithms, techniques, or methods described or illustrated herein. In particular embodiments, one or more computer systems 700 provide the functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems 700 performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems 700. Herein, reference to a computer system may encompass a computing device and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate.

[0088] This disclosure contemplates any suitable number of computer systems 700. This disclosure contemplates computer system 700 taking any suitable physical form. As example and not by way of limitation, computer system 700 may be an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system,ATTORNEY DOCKET PATENT APPLICATION 088603.011223 of 33an augmented / virtual reality device, or a combination of two or more of these. Where appropriate, computer system 700 may include one or more computer systems 700; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 700 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example and not by way of limitation, one or more computer systems 700 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 700 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.

[0089] In particular embodiments, computer system 700 includes a processor 702, memory 704, storage 706, an input / output (I / O) interface 708, a communication interface 710, and a bus 712. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.

[0090] In particular embodiments, processor 702 includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor 702 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 704, or storage 706; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 704, or storage 706. In particular embodiments, processor 702 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 702 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 702 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory 704 or storage 706, and the instruction caches may speed up retrieval of those instructions by processor 702. Data in the data caches may be copies of data in memory 704 or storage 706 for instractions executing at processor 702 to operate on; the results of previous instructions executed at processor 702 for access by subsequent instructions executing at processor 702 or for writing to memory 704 or storage 706; or other suitable data. The data caches may speed up read or write operations by processor 702.ATTORNEY DOCKET PATENT APPLICATION 088603.011224 of 33The TLBs may speed up virtual-address translation for processor 702. In particular embodiments, processor 702 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 702 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 702 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 702. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.

[0091] In particular embodiments, memory 704 includes main memory for storing instructions for processor 702 to execute or data for processor 702 to operate on. As an example and not by way of limitation, computer system 700 may load instructions from storage 706 or another source (such as, for example, another computer system 700) to memory 704. Processor 702 may then load the instructions from memory 704 to an internal register or internal cache. To execute the instructions, processor 702 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 702 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 702 may then write one or more of those results to memory 704. In particular embodiments, processor 702 executes only instructions in one or more internal registers or internal caches or in memory 704 (as opposed to storage 706 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 704 (as opposed to storage 706 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 702 to memory 704. Bus 712 may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 702 and memory 704 and facilitate accesses to memory 704 requested by processor 702. In particular embodiments, memory 704 includes random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi -ported RAM. This disclosure contemplates any suitable RAM. Memory 704 may include one or more memories 704, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

[0092] In particular embodiments, storage 706 includes mass storage for data or instructions. As an example and not by way of limitation, storage 706 may include a hard diskATTORNEY DOCKET PATENT APPLICATION 088603.011225 of 33drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 706 may include removable or non-removable (or fixed) media, where appropriate. Storage 706 may be internal or external to computer system 700, where appropriate. In particular embodiments, storage 706 is non-volatile, solid-state memory. In particular embodiments, storage 706 includes read-only memory (ROM). Where appropriate, this ROM may be maskprogrammed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 706 taking any suitable physical form. Storage 706 may include one or more storage control units facilitating communication between processor 702 and storage 706, where appropriate. Where appropriate, storage 706 may include one or more storages 706. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

[0093] In particular embodiments, I / O interface 708 includes hardware, software, or both, providing one or more interfaces for communication between computer system 700 and one or more I / O devices. Computer system 700 may include one or more of these I / O devices, where appropriate. One or more of these I / O devices may enable communication between a person and computer system 700. As an example and not by way of limitation, an I / O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I / O device or a combination of two or more of these. An I / O device may include one or more sensors. This disclosure contemplates any suitable I / O devices and any suitable I / O interfaces 708 for them. Where appropriate, I / O interface 708 may include one or more device or software drivers enabling processor 702 to drive one or more of these I / O devices. I / O interface 708 may include one or more I / O interfaces 708, where appropriate. Although this disclosure describes and illustrates a particular I / O interface, this disclosure contemplates any suitable I / O interface.

[0094] In particular embodiments, communication interface 710 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 700 and one or more other computer systems 700 or one or more networks. As an example and not by way of limitation, communication interface 710 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. ThisATTORNEY DOCKET PATENT APPLICATION 088603.011226 of 33disclosure contemplates any suitable network and any suitable communication interface 710 for it. As an example and not by way of limitation, computer system 700 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 700 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WLFI network, a WLMAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 700 may include any suitable communication interface 710 for any of these networks, where appropriate. Communication interface 710 may include one or more communication interfaces 710, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

[0095] In particular embodiments, bus 712 includes hardware, software, or both coupling components of computer system 700 to each other. As an example and not by way of limitation, bus 712 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 712 may include one or more buses 712, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

[0096] Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or moreATTORNEY DOCKET PATENT APPLICATION 088603.011227 of 33of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.

[0097] Herein, “or” is inclusive and not exclusive, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A or B” means “A, B, or both,” unless expressly indicated otherwise or indicated otherwise by context. Moreover, “and” is both joint and several, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A and B” means “A and B, jointly or severally,” unless expressly indicated otherwise or indicated otherwise by context.

[0098] The scope of this disclosure encompasses all changes, substitutions, variations, alterations, and modifications to the example embodiments described or illustrated herein that a person having ordinary skill in the art would comprehend. The scope of this disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates respective embodiments herein as including particular components, elements, feature, functions, operations, or steps, any of these embodiments may include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere herein that a person having ordinary skill in the art would comprehend. Furthermore, reference in the appended claims to an apparatus or system or a component of an apparatus or system being adapted to, arranged to, capable of, configured to, enabled to, operable to, or operative to perform a particular function encompasses that apparatus, system, component, whether or not it or that particular function is activated, turned on, or unlocked, as long as that apparatus, system, or component is so adapted, arranged, capable, configured, enabled, operable, or operative. Additionally, although this disclosure describes or illustrates particular embodiments as providing particular advantages, particular embodiments may provide none, some, or all of these advantages.

Claims

ATTORNEY DOCKET PATENT APPLICATION 088603.011228 of 33CLAIMSWhat is claimed is:

1. A method comprising, by a computing system:obtaining a mnemonic phrase representing a master cryptographic secret; deriving, from the mnemonic phrase, one or more hardened private keys corresponding to one or more hierarchical deterministic derivation paths;performing a one-time verifiable secret sharing (VSS) operation to split the mnemonic phrase and the one or more hardened private keys into a plurality of cryptographic shares, wherein each cryptographic share comprises at least a share of the mnemonic phrase and a share of the one or more hardened private keys;distributing the plurality of cryptographic shares to a plurality of computing devices associated with a multi-party computation (MPC) environment;responsive to distributing the plurality of cryptographic shares, deleting a complete version of the mnemonic phrase and the one or more hardened private keys such that no single computing device stores a complete private key or complete mnemonic phrase; and performing a cryptographic transaction by executing an MPC signing protocol cooperatively using two or more of the plurality of computing devices based on their respective cryptographic shares.

2. The method of Claim 1, further comprising:reconstructing the mnemonic phrase by obtaining cryptographic shares from a threshold number of the plurality of computing devices; andexporting the reconstructed mnemonic phrase to an external single-key wallet.

3. The method of Claim 1, wherein obtaining the mnemonic phrase comprises: importing an existing mnemonic phrase from a single-key wallet compliant with a hierarchical deterministic wallet standard.

4. The method of Claim 1, wherein obtaining the mnemonic phrase comprises: generating the mnemonic phrase in accordance with a hierarchical deterministic wallet standard.ATTORNEY DOCKET PATENT APPLICATION 088603.011229 of 335. The method of Claim 1, wherein performing the one-time VSS operation further comprises:generating validation data comprising cryptographic commitments and cryptographic proofs enabling verification of correctness of the cryptographic shares without revealing the mnemonic phrase or the one or more hardened private keys.

6. The method of Claim 5, further comprising:performing, based on the validation data, a multi-round verification process prior to activating the cryptographic shares for MFC signing.

7. The method of Claim 6, wherein the multi-round verification process comprises: a first round for commitment and proof distribution;a second round for commitment and parameter verification;a third round for decommitment and consistency verification; anda fourth round for final validation and cryptographic shares activation.

8. The method of Claim 6, wherein each of the plurality of computing devices stores its respective cryptographic share in a non-activated state until the multi-round verification process is completed.

9. The method of Claim 1, further comprising:storing at least one cryptographic share as a backup in a secure element.

10. The method of Claim 9, wherein the secure element comprises a smart card or hardware-based secure storage device.

11. The method of Claim 9, wherein storing at least one cryptographic share in the secure element comprises:applying one or more data compression or storage optimization techniques to reduce or optimize storage size of the at least one cryptographic share such that the at least one cryptographic share is efficiently stored for backup in the secure element.ATTORNEY DOCKET PATENT APPLICATION 088603.011230 of 3312. The method of Claim 9, wherein the cryptographic shares are provisioned into the secure element during the one-time VSS operation.

13. The method of Claim 9, wherein each computing device stores its respective cryptographic share in a device-specific secure element.

14. The method of Claim 1, wherein the mnemonic phrase comprises a sequence of words encoding an entropy that is used to derive the master cryptographic secret in accordance with a hierarchical deterministic wallet standard.

15. The method of Claim 1, wherein deriving the one or more hardened private keys comprises performing one or more hardened derivation operations corresponding to at least one of a purpose level, coin type level, or account level.

16. The method of Claim 1, further comprising:deriving one or more non-hardened child keys at one or more of the plurality of computing devices using their respective cryptographic shares, wherein the one or more nonhardened child keys are used for address generation and cryptographic transaction signing within the MPC environment.

17. The method of Claim 1, wherein the cryptographic transaction comprises broadcasting a signed transaction to a distributed ledger network.

18. The method of Claim 1, wherein the plurality of computing devices associated with the MPC environment comprises:a mobile device;a web browser;a cloud service;a hardware device; ora standalone personal computer (PC) application.ATTORNEY DOCKET PATENT APPLICATION 088603.011231 of 3319. One or more computer- readable non-transitory storage media embodying software that is operable when executed by a computing system to:obtain a mnemonic phrase representing a master cryptographic secret;derive, from the mnemonic phrase, one or more hardened private keys corresponding to one or more hierarchical deterministic derivation paths;perform a one-time verifiable secret sharing (VSS) operation to split the mnemonic phrase and the one or more hardened private keys into a plurality of cryptographic shares, wherein each cryptographic share comprises at least a share of the mnemonic phrase and a share of the one or more hardened private keys;distribute the plurality of cryptographic shares to a plurality of computing devices associated with a multi-party computation (MPC) environment;responsive to distributing the plurality of cryptographic shares, delete a complete version of the mnemonic phrase and the one or more hardened private keys such that no single computing device stores a complete private key or complete mnemonic phrase; and perform a cryptographic transaction by executing an MPC signing protocol cooperatively using two or more of the plurality of computing devices based on their respective cryptographic shares.

20. A system comprising:one or more processors; andone or more computer- readable non-transitory storage media coupled to the one or more processors and comprising instructions operable when executed by the one or more processors to cause the system to:obtain a mnemonic phrase representing a master cryptographic secret; derive, from the mnemonic phrase, one or more hardened private keys corresponding to one or more hierarchical deterministic derivation paths;perform a one-time verifiable secret sharing (VSS) operation to split the mnemonic phrase and the one or more hardened private keys into a plurality of cryptographic shares, wherein each cryptographic share comprises at least a share of the mnemonic phrase and a share of the one or more hardened private keys;distribute the plurality of cryptographic shares to a plurality of computing devices associated with a multi-party computation (MPC) environment;ATTORNEY DOCKET PATENT APPLICATION 088603.011232 of 33responsive to distributing the plurality of cryptographic shares, delete a complete version of the mnemonic phrase and the one or more hardened private keys such that no single computing device stores a complete private key or complete mnemonic phrase; andperform a cryptographic transaction by executing an MPC signing protocol cooperatively using two or more of the plurality of computing devices based on their respective cryptographic shares.

Images