Competitive Projects

Overview

Throughout late 2024 and early 2025, we investigated to identify optimal solutions for key management, storage, handling, and transaction signing. This report indicates projects whose solutions most appropriately align with our conceptual design as a foundation for development of a custom solution that meets our specific requirements. From this review, we aim to integrate the optimal best practice and innovative methodologies to enhance the security and efficiency of our system.

The considered Decentralized Protocols for Key and Wallet Management that we investigate are: Atomic swap, Lit protocol, Entropy xyz, dWallet, Torus and Passport protocol.

Atomic Swap

An atomic swap is a cryptographic scheme enabling two parties to swap assets in a trustless environment such that either both transfers are made or none are. An article we came across presents a novel off-chain atomic swap protocol for swapping ownership of crypto assets based on two-party Multi-Party Computation (2-2 MPC) wallets. This approach reduces the problem of swapping assets to a concurrent revelation of secrets (i.e., shares of keys) between two users, hoping that, in the end, one user will control the first 2-2 MPC wallet exclusively and the other will control the second 2-2 MPC wallet exclusively. The proposed solution concept employs a release mechanism through a gradual way supported by continuous zero-knowledge (ZK) proofing to ensure fairness and security throughout the protocol.

Figure 1: Illustration of the operation of an atomic swap. Source: https://www.bitskwela.com

Protocol Overview

• Setup: Both users initially have a key share in two separate 2-2 MPC wallets and desire to exchange.

• Goal: After exchange, one user will have both key shares of the first wallet (owning it outright) and the other will have both key shares of the second wallet.

• Challenge: The simultaneous disclosure of the key shares should avoid either side from profiting by an untimely termination of the protocol after learning the other's secret but not disclosing their own yet.

Gradual Release Mechanism

The solution implements a bit by bit disclosure mechanism for the key shares so that neither side can gain an undue benefit from a premature termination:

• Process: The user gradually reveals their secret share, one bit at a time, to the other party via multiple rounds of exchange.

• Zero-Knowledge Verification: Zero-knowledge proofs verify at each stage that the bits revealed are pertaining to the actual key share without compromising the whole share too soon. This ensures that both parties are becoming more committed to the correct secrets.

• Fairness: The gradual release offers close parity in the amount of crucial share information held by each party at any given time.

Security Against Malicious Behavior

• Early Termination: If a party (Party A) is maliciously provided the other's (Party B's) entire key share and ceases to communicate before sharing their own fully, then Party B is not exposed. Since a large portion of Party A's valuable share is already established (e.g., 200 out of 256 bits), Party B can brute-force the last bits (e.g., 2⁵⁶ possibilities for 56 bits). Although computationally intensive, this is possible compared to guessing all 256-bit key (2²⁵⁶ possibilities), enabling the cheated party to rebuild a legitimate share and claim ownership of their corresponding wallet. However, depending on the amount being swapped and the number of remaining bits that need to be guessed, the cost of a brute-force search could be considerable. Additionally, the time required for a brute-force search could allow a malicious party to move their assets if they are not properly locked.

• Outcome: At the end of the protocol, Party A possesses both shares of the first 2-2 MPC wallet, and Party B possesses both shares of the second, having successfully done the atomic swap with zero on-chain interaction.

Technical Advantages

• Off-Chain Efficiency: Since the swap is done off-chain, the protocol avoids blockchain transaction fees and latency and instead employs only peer-to-peer communication and cryptographic assurance.

• ZK Assurance: Continuous ZK verification eliminates the need for a trusted third party or timelocking, making it simpler.

• Scalability: The approach can be scaled to any 2-2 MPC wallet setup, provided the supporting signature scheme (e.g., ECDSA) allows for key share reconstruction.

Challenges and Considerations

• Computational Overhead: Bit by bit reveal and ZK proof generation use a high amount of computational resources, especially for higher key sizes.

• Communication Rounds: The protocol involves numerous rounds, which could introduce latency or risk of network disruption.

• Brute-Force Feasibility: The security model assumes brute-forcing the remaining bits is possible for the cheated party, depending on available key share size and computational power.

Summary

The proposed off-chain atomic swap protocol employs 2-2 MPC wallets and a delayed release mechanism to achieve trustless ownership transfer. By unveiling key shares bit by bit with zero-knowledge verification, the protocol ensures fairness and prevents malicious exits, ultimately allowing each party to gain full control of their corresponding wallet. The new solution avoids reliance on the blockchain, offering a privacy-preserving, scalable solution to traditional atomic swaps. Its practical deployment would, however, require mitigation of computational and communication overhead for successful real-world use.

Lit Protocol

Lit Protocol is a decentralized network that employs programmable encryption and keys to enable secure, autonomous operations for AI agents, blockchain interoperability, and user-owned data management. It supports complex cross-chain operations with enhanced security, ensuring unprecedented data sovereignty without centralized keys or single points of failure. By embedding programmable signing and encryption, Lit Protocol empowers builders to create innovative, secure, and interoperable digital ecosystems.

In Lit Protocol, users do not hold key shares directly. Instead, the private keys (e.g., for Programmable Key Pairs or network-level encryption) are split and held by the Lit nodes using threshold cryptography. Users gain access by proving ownership or meeting access control conditions (like wallet signatures, auth methods, or NFT ownership), rather than by managing part of the key themselves. Additionally, Lit nodes run inside Trusted Execution Environments (TEEs), which ensure that key operations (like signing or decryption) happen securely and are only triggered when access conditions are met implying the non-custodial nature of the system despite users not holding the keys directly.

Lit Protocol operates three various networks: Datil Mainnet, Datil-test, and Datil-dev. Datil Mainnet is for production-ready apps, and Datil-test and Datil-dev are testnets for development and experimentation respectively.

Figure 2: Lit protocol. Source: https://spark.litprotocol.com

Node Architecture

• Encrypted Virtual Machines: Each Lit node is an encrypted virtual machine (VM) on proprietary processors with isolated Trusted Execution Environments (TEEs). No one, not even the node operator, can see the contents inside or tamper with the execution environment.

• Deno JavaScript Runtime: Each node includes a Deno JavaScript runtime, enabling execution of secure, sandboxed JavaScript code (Lit Actions).

• MPC Wallet Shards: Nodes exchange parts of MPC wallets between them. The key shares are established using DKG.

• The Recovery Party: In addition to regular Lit nodes, there is a separate group called the Recovery Party. This group plays a critical role in the network-level recovery process by providing “blinders” to assist in decrypting encrypted root key backups. A threshold (typically 2/3) of Recovery Party members must participate for recovery to succeed. They do not hold key shares, sign data, or participate in governance or staking. Lit Protocol’s Recovery Party design minimizes trust but doesn’t eliminate it, it shifts trust from a single custodian (as in centralized systems) to a distributed threshold-based model with redundant roles (nodes + recovery party), increasing resilience while still depending on some honest majority assumptions.

Programmable Key Pairs (PKPs)

• Definition: PKPs are pairs of ECDSA public and private keys, which the Lit network generates using DKG. Every PKP is minted as an ERC-721 NFT on the Chronicle Yellowstone blockchain, which is a proprietary EVM-compatible rollup serving as Lit's coordination layer.

• Functionality: PKPs are decentralized MPC wallets with private key shares distributed over Lit nodes. Multiple nodes must collectively create a valid signature to prevent illegal access.

• Integration with Lit Actions: PKPs may be governed by Lit Actions, immutable JavaScript scripts that can act like smart contracts in the Lit network. Such scripts enable complex access control logic, such as conditional signing against on-chain or off-chain data.

Wrapped keys

• Features: Generated within a single Lit node's TEE, or imported from an existing private key. Encrypted via the MPC Lit network, and stored within Lit's private Dynamo DB instance. Support a wider range of cryptographic curves, enabling interaction with more blockchains than PKPs. Allow for private key import and export, providing flexibility for users with existing keys. Fully decrypted within a single node's TEE when used. Can be controlled by Lit Actions, enabling advanced use cases and key management.

• Reasons for their use: Blockchain Compatibility - Wrapped Keys support signing with curves not currently supported by PKPs, allowing interaction with a broader range of blockchains. Key Import/Export - Users can import existing private keys or export keys for use in other systems, offering greater flexibility and interoperability. Legacy System Integration - Wrapped Keys may be easier to integrate with existing systems that expect traditional private key management.

• PKPs vs. Wrapped Keys: In summary, PKPs offer a highly secure solution for supported blockchains, while Wrapped Keys provide greater flexibility and compatibility at the cost of a slightly different security model. The choice between them depends on the specific requirements of your application, the blockchains you need to interact with, and your security priorities.

Cross-Chain Capabilities

• State Reading: Lit Actions can read state from most EVM-compatible blockchains, the Cosmos chain, and Solana.

• Transaction Signing: With Lit Actions, PKPs can sign transactions on any ECDSA-based blockchain, enabling cross-chain interaction.

• Conditional Access: On-chain state from these chains can be used as condition to access PKPs.

Payment Mechanisms

The access to the resources of the Lit network is controlled through a payment system based on the Chronicle Yellowstone blockchain:

• Capacity Credits - They are NFT tokens minted on Chronicle Yellowstone that grant the holder a variable number of requests per second within a specified time frame (e.g., a week). They allow developers to reserve network capacity in advance for their applications.

• Lit Test Tokens (tstLPX) - Now deployed on the Datil Mainnet Beta and testnets, the tokens can be used to cover the cost of transactions on Chronicle Yellowstone, such as minting Capacity Credits or triggering responses from smart contracts. They are not of any inherent value and will be eliminated through the LITKEY token when the V1 is released.

• ERC-5573 SIWE Proof - Payment is made by submitting an ERC-5573 Sign-In with Ethereum (SIWE) proof of wallet control on Chronicle Yellowstone. This proof authenticates the user's wallet, enabling the use of Capacity Credits or test tokens to consume Lit services.

Summary

The Datil networks of Lit Protocol, Mainnet for production and Datil-test/dev for development, offer a secure, decentralized platform for key management and computation. Each node runs in an encrypted virtual machine using Deno and holds MPC wallet fragments generated via Distributed Key Generation (DKG). Users do not hold key shares directly; instead, keys are split across nodes using threshold cryptography. Access is granted through verifiable conditions like wallet signatures or social logins, rather than by managing keys directly.

This model may seem custodial, but Trusted Execution Environments (TEEs) ensure that key operations, such as signing or decryption, are executed securely and only when access conditions are met, implying the non-custodial nature of the system. However, while this design removes direct custody from nodes, trust is shifted to the manufacturers of the TEEs and the correctness of the protocol implementation, both of which must prevent misuse of keys the user does not control. Additionally, although nodes cannot use the key independently, they can still censor transactions by refusing to participate. PKPs are issued as ERC-721 NFTs and function as programmable MPC wallets controlled by Lit Actions, enabling cross-chain state reading and transaction signing. While PKPs offer a high-security solution for supported blockchains, they lack the broader compatibility and flexibility provided by Wrapped Keys, which trade off some security for interoperability.

In addition to regular nodes, Lit uses a separate group called the Recovery Party to support network-level key recovery. While this model reduces trust through threshold cryptography and role separation, it still depends on an honest majority assumption. Lit Protocol supports a range of use cases, powered by Capacity Credits and Lit Test Tokens on Chronicle Yellowstone. This infrastructure positions Lit as a general-purpose platform for Web3 developers seeking a balance of decentralization, programmability, and usability.

Entropy.xyz

Entropy.xyz is a decentralized network that seeks to provide secure, programmatic custody of digital assets through MPC wallets. Employing threshold cryptography and a novel programmable framework, Entropy enables users to construct highly customizable wallet logic. An initial use case for Entropy is a decentralized asset custodian, where the Program defines under what conditions funds or assets can be moved. Further use cases for Entropy Programs include intent settlement and attestations. An asset custodian should be able to do a couple of things that most wallets can’t:

• User may have funds across multiple addresses, and maybe across multiple chains. An asset custodian should be a single interface between the user and all of these accounts.

• An asset custodian should be able to represent multi-user accounts: accounts with shared access by multiple parties. The permissions for each of these parties may be different.

• A user should be able to specify arbitrary constraints on how funds move through the custodian.

• The custodian should be well-secured, while anticipating the need for emergency scenarios for secure account recovery.

Figure 3: Entropy.xyz network. Source: https://mirror.xyz

Account and Wallet Creation

• User Setup: A user initiates an account on the Entropy decentralized network and establishes an MPC wallet.

• Program Definition: The user, along with the MPC wallet, defines a Program, a custom logic script that determines whether a requested transaction should be signed or not. The Program is fed as input to the message to be signed and any other information provided by the Program creator, such as off-chain data obtained through external calls.

• In the Entropy scheme, key shares are generally held by nodes on the Entropy Network, while with Entropy’s private access mode, the user holds onto one or more key shares.

Signing Process

• Validation: When a transaction request is received, the Program verifies it based on its predefined logic. If the Program gives True as a response, nodes of the Entropy network will sign the transaction collectively using a threshold signature protocol. However, the current implementation supports only n-of-n signing, which means that all nodes must sign the transaction. The protocol never reconstructs the full private key but keeps it safe by distributed key fragments generated via DKG.

• Output: The signed transaction is sent to the user, who can present it to the destination blockchain.

Programs: Enhanced Smart Contracts

Entropy's Programs are an advanced version of the old smart contracts, with more flexibility and features:

• Off-Chain Requests: Programs have the ability to tell nodes to issue external calls (e.g., HTTP request) to retrieve off-chain information, such as price feeds, weather forecast, or API responses, enhancing decision-making features.

• Private State: In contrast to on-chain smart contracts, Programs can store private state variables, holding sensitive logic or data secret.

• Cost-Effective Computation: Off-chain operation of computationally expensive operations by Programs reduces the gas costs and latency associated with on-chain execution.

• Automation: Programs execute tasks, recurrent or timed, automatically without human intervention, performing arbitrary computation.

• Self-Modification: Programs are able to alter their own sets of rules dynamically based on agreed terms so that adaptive behavior can be attained as time elapses.

AI Agents and Risk Management

• Core Idea: The core innovation of Entropy is to enable Programs to be AI agents. Parameters such as risk, expense budget, or investment policy are defined by users, allowing such agents to self-manage their MPC wallets. The Entropy network acts as custodian, using the AI-driven logic while ensuring security using its decentralized node network.

• User Empowerment: This framework allows users to offload complex decision-making to their Programs that are reliable, programmable resources that manage assets across various ECDSA networks.

Network Design and Incentives

• Node Stability: To prevent runaway node churn (continual joining and leaving), Entropy uses systems that incentivize node operators to remain active indefinitely. Such incentives may include staking requirements, reputation mechanisms, or economic incentives based on uptime and reliability.

• Node Limit and Pooling: There is a limit to the number of active nodes in the network. The moment this limit is met, node operators are grouped into pools, with each pool receiving key shares as a group and performing threshold signing as a group. While this pooling leads to improved scalability, it introduces some centralization because pool coordination has a tendency to concentrate power among fewer participants.

Technical Advantages

• The use of ECDSA in the MPC wallet enables broad compatibility across multiple blockchains such as Bitcoin and Ethereum that also rely on ECDSA, reducing the need for chain-specific cryptographic implementations, though some chain-specific logic (e.g., transaction formatting) may still be required.

• Decentralized Custody: Single points of failure are eliminated by threshold cryptography, and nobody, user or node, has the entire private key.

• Programmability: Programmability via off-chain data integration and self-modifying logic makes Programs an extremely handy instrument for advanced automation and AI-driven asset management.

Challenges and Trade-Offs

• Centralization Risk: The node pooling system, being a scalability requirement, can erode the decentralization culture of the network if pool operators gain excessive influence.

• Complexity: Restricting and locking down AI-run Programs as a requirement brings with it complicated design to prevent unintended action or vulnerabilities, especially since they possess off-chain capabilities.

• Performance: Threshold signing across a large number of nodes could lead to latency, though Entropy's design mitigates this as much as possible with effective protocols.

Summary

Entropy.xyz provides a decentralized network that allows users to build MPC wallets compatible with any ECDSA blockchain, combined with programmable logic (Programs) as advanced smart contracts. The Programs include off-chain requests, private state, and self-modifying rules, providing a foundation for AI agents to automatically handle assets based on user-defined risk tolerance and parameters. In the Entropy scheme, key shares are generally held by nodes on the Entropy Network in the decentralized asset custodian mode, while in Entropy’s private access mode, the user holds one or more key shares. The network should use threshold signing to secure transactions without private key reconstruction, while its node cap and pooling mechanism pose a trade-off between decentralization and scalability. However, the current implementation supports only n-of-n signing, which means that all nodes must sign the transaction. Such cutting-edge implementation brings Entropy to the forefront of programmable, AI-driven custody solutions for Web3.

dWallet

dWallet is a new Web3 primitive created by dWallet Labs, based on the 2PC-MPC protocol. It is a programmable, transferable signing mechanism aiming to be usable with any blockchain by supporting multiple signature schemes and enabling flexible, decentralized signing.

Structure

dWallet Network accounts are analogous to Ethereum accounts, with each account being capable of owning a dWallet. A dWallet is a bit like an NFT, a unique, moveable asset that is associated with an account but it’s actually an MPC wallet. It is controlled by two parties: the user (an account in the dWallet Network) and the network itself, who together hold the second key share. There is an option which allows replacing the DKG with the import of an existing private key - in this scenario the user holds the full original private key, so it cannot be used in use cases where external logic must be enforced (e.g. liquidation). In cases where the user participation is not preferable, the user share can be stored publicly, such that anyone can generate the signature together with the network, making it redundant, effectively giving full control of the dWallet to the smart contract enforcing the logic.

Key Features

• User Control: Although all the network nodes might be malicious, the user is still in control through their key share, which guarantees asset protection.

• Encryption and Transfer: Each account has a public encryption key. To transfer a dWallet, the user's key share is encrypted with the recipient's public encryption key and sent over the network. The recipient pays for a gas fee in order to receive the transfer, decrypting the share with their private key in order to take control.

• Multi-Chain Support: dWallets are designed to create signatures for any blockchain so that native multi-chain asset support can be achieved without wrappers or bridges.

Technical Details

The manual lacks an in-depth explanation of the mechanisms but showcases the use of 2PC-MPC to encapsulate the network complexity into a single "party" for the user. Encapsulation gives the impression that the user interacts with the network as if it is a single party regardless of the multiple nodes involved.

Presignatures and Transaction Signing

The protocol uses a presignature mechanism to enhance performance. Presignatures are partially computed signatures, independent of the message to be signed, that can be precomputed by the network nodes. These precomputed elements allow the signing process to be highly efficient when a user initiates a transaction. When a transaction request is made, the user submits their partial signatures (cryptographic data) and the message to be signed. The network calculates the signature homomorphically over the encrypted network share, and combines it with the user input and a precomputed presignature which results in an encrypted valid signature, which will be decrypted by a threshold of network participants (threshold homomorphic decryption - MPC).

2PC-MPC

The dWallet Labs protocol 2PC-MPC (Two-Party Computation Multi-Party Computation) is a cryptographic multi-party system that is capable of producing non-collusive ECDSA signatures. Detailed in its announcement (ika.xyz/blog/announcing-2pc-mpc), the protocol enables a signature to be co-signed by two separate parties: the user and an independent network, which can be hundreds or thousands of nodes large. Unlike traditional multi-party computation (MPC) protocols, 2PC-MPC does not allow the network to act alone and steal a user's assets, as the user's key share is essential to the creation of a signature. Compared to MPC-CMP, which is a rival standard, offering fast and secure signing for MPC wallets, dWallet’s 2PC-MPC prioritizes massive decentralization and non-collusiveness over single-round efficiency, targeting a fundamentally different application.

Figure 4: 2PC-MPC Zero Trust. Source: https://chainflow.io

• Key Structure: The user's private key material is split into two pieces: one in the possession of the user and one managed by the network. The network's piece is itself a threshold-based combination of a set of key shares and signatures from its nodes into one logical "party" in the two-party scheme. The nested structure hides the internal complexity of the network and appears to the user as one entity.

• Security: The protocol guarantees non-collusiveness, the network, even if fully adversarial (i.e., all the nodes are malicious), cannot produce a valid signature without the user. This represents a huge departure from other MPC signature schemes, which scale very poorly in permissionless settings and are susceptible to a small subset of colluding nodes. The security model presumes that users safeguard their share of the dWallet and any associated decryption or authentication keys. If this assumption is not upheld, the compromise of these elements could allow attackers to gain unauthorized access over the associated dWallet, leading to potential loss of funds or control. There is no official documentation on key refresh, rotation, or key share re-generation (e.g., refreshing a dWallet’s secret Key Share) in dWallet’s public documentation.

• Scalability: Explained in its documents 2PC-MPC replaces peer-to-peer (P2P) communication with broadcast communication and hence enables the protocol to scale to hundreds or thousands of nodes while maintaining the user's O(1) complexity. The user can hence seamlessly engage with a highly decentralized network without overwhelming the user's computational or communications capabilities.

Summary

The dWallet Network introduces a novel Web3 primitive through its 2PC-MPC protocol, enabling a decentralized, secure, and scalable signing mechanism for multi-chain asset management. By combining user-controlled key shares with a non-collusive network, dWallets ensure robust asset protection and seamless interoperability across blockchains without relying on wrappers or bridges. Unlike traditional MPC protocols, 2PC-MPC's communication and encapsulation of network complexity allow it to scale efficiently to thousands of nodes while maintaining user simplicity and security. This positions dWallet as a significant advancement in decentralized wallet technology, prioritizing user sovereignty and cross-chain functionality. However, the 2PC-MPC design could also present a challenge in important security tasks such as key refresh, rotation, or key share re-generation, and a user’s loss of their key share could result in permanently locking (losing) their funds.

Torus

Torus is an open-source key management system that is designed to provide a frictionless, passwordless Web3 app authentication experience while providing non-custodial security guarantees. In the Torus documentation, two distinct methods for private key generation are mentioned. One, referred to as the Base Torus Key Infrastructure method employs a 2-out-of-3 (2/3) Shamir Secret Sharing (SSS) mechanism to share and store private keys, blending Web2 authentication practices with Web3 cryptographic methodologies. The other method uses Distributed Key Generation (DKG) via a cryptographic scheme called Asynchronous Verifiable Secret Sharing (AVSS), performed solely by the nodes, to generate buffers of unassigned keys ahead of time, which are then assigned to users only when they request new keys. Below is an outline of the process:

Figure 5: How Torus works. Source: https://docs.tor.us

Key Generation and Distribution (Base Torus Key Infrastructure mode)

• Shamir Secret Sharing Setup: During account setup, the user generates a private key that is split into three shares with a 2/3 SSS threshold. This allows any two of the shares to recover the key while providing security and redundancy. The shares are distributed as follows:

  • ShareA (Device Share): Stored locally on the user device. The device-specific implementation is utilized.

  • ShareB (Network Share): Governed by the Torus network, a distributed collective of node operators. The share is further divided amongst the nodes through a second secret sharing layer, in a way that no single node possesses the complete ShareB. Access to ShareB encompasses the user being logged in via an OAuth2 login flow, utilizing Web2 standards such as Google, Reddit, or passwordless authentication methods (e.g., email-based magic links).

  • ShareC (Backup/Recovery Share): A recovery share for secure storage by the user. ShareC can be explicitly created and stored offline (e.g., on another device, USB drive, or paper backup) or deterministically calculated from high-entropy user input, e.g., a secure password, security question responses, or hardware token. Deterministic computation generally entails hashing the input with a cryptographically secure hash function (e.g., SHA-256) to produce a share with sufficient randomness.

Authentication and Key Reconstruction

• Login Process: For retrieving the private key of the user, the user goes through a login with a supported OAuth2 provider. The Torus SDK, which is part of the application, facilitates this process:

  • The user device provides ShareA.

  • Following successful OAuth2 authentication, the Torus network reconstructs and gives back ShareB through coordinating over its nodes, each of which verifies the identity of the user without any single node holding the complete share.

  • The SDK employs Lagrange interpolation to combine ShareA and ShareB and reconstruct the local private key on the user's device. ShareC is not utilized for daily logins but as a failback.

• Web2-Like Experience: By employing OAuth2, Torus emulates familiar Web2 login flows, reducing sign-up friction for non-technical users while maintaining Web3 security.

Recovery Mechanism

• Lost Device Scenario: In the case of device loss (and thus ShareA) by the users, they can recover their key using ShareB and ShareC:

  • ShareB is retrieved via OAuth2 authentication with the Torus network.

  • ShareC is restored from the user's secure backup or re-derived from their high-entropy input (e.g., password or security questions).

  • The two shares are summed to re-create the private key, ensuring account recovery without the need for a central authority.

• Censorship Resistance: 2/3 threshold protects the Torus network from censoring access. Even the nodes, if not willing to provide ShareB, cannot prevent the user from rebuilding the key from ShareA (device) and ShareC (backup), with non-custodial control.

Key Generation and Distribution (Precomputed mode)

To improve efficiency, Torus avoids running key generation on demand by pre-generating buffers of unassigned keys. These are assigned to users only when needed, enabling fast and scalable onboarding. This process uses Distributed Key Generation (DKG) with Asynchronous Verifiable Secret Sharing (AVSS), a cryptographic scheme that is fully asynchronous and eliminates the need for a complaint phase provided a small zero knowledge proof is used. This results in a simpler and more robust protocol, with constant communication rounds even in adversarial settings. Each participating node ends up with a share of a master polynomial, formed by summing individual polynomials generated by all nodes. The constant coefficient of this master polynomial serves as the user’s private key. Since randomness is contributed by a threshold of nodes, no subset below the threshold can reconstruct the key.

Torus operates in epochs, where a rotating set of nodes manages key infrastructure. At each epoch transition, only a minimal state namely, mappings of TorusIDs to user keys, is transferred. Proactive Secret Sharing (PSS) is used for secure key migration. Instead of copying shares across epochs, which poses security risks and limits flexibility, PSS reshares the existing secrets by running multiple secret sharing protocols in parallel. Each node treats its existing share as a secret, and the resulting shares are combined, weighted by Lagrange coefficients to produce a fresh, secure resharing of the original secret.

Technical Details

• Distributed Key Generation (DKG): In some deployments, the setup key generation can occur via a DKG protocol between the network and the user's device so that the entire key is never held by anybody during setup.

• High-Entropy Backup: In ShareC, deterministic generation requires the use of inputs with sufficient entropy to resist brute-force attacks.

• Security Guarantees: ShareB of the Torus network is split across permissioned nodes with eventual plans for complete decentralization. The user retains sovereignty because nobody, the network or the OAuth provider has access to the entire key in isolation.

Summary

The Shamir's Secret Sharing and OAuth2 authentication are combined by the Torus workflow to yield a non-custodial, user-friendly key management system. ShareA resides on the user's device, ShareB is managed and recovered via the Torus network using Web2 login mechanisms (i.e., Google, Reddit), and ShareC is a recovery of high entropy for backup. A two out of three threshold design provides security, redundancy, and anti-censorship, combining Web2 usability with Web3 decentralization.

Passport Protocol

Passport Protocol is a new decentralized platform for revolutionizing Web3 key management and transaction signing with MPC. It introduces social logins, programmable authentication, and intelligent transactions, building on the shortcomings of self-custody, custodial, and MPC variants. Built from peer-reviewed cryptography and hardened enclaves.

Core Features

• Social Login Auth: Passport includes OAuth-based authentication, enabling simple onboarding through familiar Web2 channels.

• Programmable Automated Transactions: Developers can create immutable rules of transaction signing, determining what, when, and how transactions are done, so that full automation is possible without requiring user intervention.

• DKLS23 Algorithm: Passport uses the DKLS23 threshold signature algorithm, a high-performance MPC-TSS. DKLS23 is very low-latency high-performance without the computationally costly Paillier operations of earlier MPC protocols like GG18 or CGGMP20. It supports secure ECDSA signing in only two communication rounds, which increases efficiency.

• Distributed Key Shares: Private keys are split into shares with DKG and stored privately among network nodes, never with the user or any single party. This eliminates points of failure and offers robust fault tolerance.

• Secure Enclaves: Key shares are encrypted and stored in secure enclaves, hardware-isolated spaces blocking access, even from node operators, keeping data private.

• Roadmap to Public Protocol: Beginning from replicated internal databases for state management in a centralized manner, Passport will transition to a decentralized approach.

• This model may seem custodial, but Trusted Execution Environments (TEEs) ensure that key operations, such as signing or decryption, are executed securely and only when access conditions are met, implying the non-custodial nature of the system. However, while this design removes direct custody from nodes, trust is shifted to the manufacturers of the TEEs and the correctness of the protocol implementation, both of which must prevent misuse of keys the user does not control. Additionally, although nodes cannot use the key independently, they can still censor transactions by refusing to participate.

Figure 6: Passport Network. Source:https://0xpass.io

Passport Protocol: A Programmable and Network-Managed MPC Solution

Passport Protocol reframes MPC-based key management through a programmable, network-distributed solution:

• Network-Only Key Distribution: Passport stores all key shares on its network nodes. This removes the burdens of key management at the user level while aiming to maintain non-custodial characteristics through decentralization and the use of TEEs.

• Programmable Infrastructure: The protocol offers tunable, immutable rules for transaction authentication and governance. There is some logic embeddable in a Passport Program such that onboarding and transacting experience can be tailored.

• Security: With the utilization of DKLS23 and secure enclaves, Passport ensures that no one, not the dApp, wallet adapter (0xPass), node operators, or infrastructure providers, gets to hold key shares. The private key is not reconstructed even at signing.

• Automation and Flexibility: Transactional workflows are automatable by developers for the first time.

Technical Implementation

• DKG and Threshold Signatures: When making keys, DKG produces shares that are distributed among nodes. DKLS23 supports threshold ECDSA signature generation, such that a quorum (e.g., 2-out-of-3 nodes) can produce a signature without reconstructing the full key. This balances security and efficiency.

• Secure Enclaves: Databases on every node store key shares encrypted in a secure enclave for confidentiality even in the event of a compromised node. Metadata and state are already managed via replicated internal databases with upcoming on-chain integration.

• 0xPass Wallet Adapter: Passport provides a "Connect Wallet" capability via the 0xPass adapter, unifying social logins and MPC wallets in dApps, lightening the integration load for developers.

• The Halides Model is Passport's performance-focused approach to distributed key management. Instead of relying on many independent nodes, it introduces a central orchestrator that handles communication and authentication, while nodes focus solely on storing key shares now split into smaller “halides.” This reduces network load, improves scalability, and maintains a closed, permissioned structure for better control and efficiency. It also sets the stage for multiple orchestrator vendors in the future. This design introduces centralization risks, such as potential single points of failure or censorship. Future support for multiple orchestrators aims to mitigate these concerns.

Summary

Passport Protocol differs from traditional MPC solutions by being programmable and network-controlled key distribution. Utilizing the DKLS23 algorithm and secure enclaves, it provides fast threshold signatures and encrypted key storage, with its social login capability and auto-transactions redefining onboarding and post-authentication processes. As a middle ground between custody and self-custody solutions, Passport aims to achieve a non-custodial, programmatic solution that allows developers to customize authentication and transaction logic, and eventually expand to become a decentralized public protocol. Though this model appears custodial, TEEs ensure keys are only used under strict conditions, preserving non-custodial security. However, trust shifts to TEE manufacturers and protocol correctness. While nodes can't misuse keys, they can still censor transactions by refusing to participate. The Halides Model boosts performance by centralizing authentication and communication through an orchestrator, while nodes only store split key fragments. This closed, permissioned setup enhances efficiency but introduces risks like potential censorship or orchestrator failure. Planned support for multiple orchestrators aims to reduce these risks.

Summary

The investigated decentralized protocols: Atomic Swap, Lit Protocol, Entropy.xyz, dWallet, Torus, and Passport Protocol provide innovative solutions that align with our project's vision for secure and scalable key and wallet management. Atomic Swap's off-chain efficiency minimizes transaction fees and latency through peer-to-peer cryptographic assurance, supporting our goal of cost-effective cross-chain operations. Entropy.xyz's AI-driven Programs enable user-defined automation for complex asset management, aligning with our aim to integrate intelligent, programmable solutions. dWallet's 2PC-MPC protocol supports native multi-chain functionality with user-controlled, non-collusive key shares, ensuring robust interoperability and security. Lit Protocol, Torus, and Passport Protocol stand out for their advanced node-based key management: Lit Protocol leverages encrypted virtual machines and distributed key generation (DKG) for secure transaction signing; Torus employs a 2/3 Shamir Secret Sharing scheme, distributing one key share to the user, one for recovery, and one across network nodes using a second layer of secret sharing, ensuring no single node holds the complete key; and Passport Protocol uses the DKLS23 algorithm and secure enclaves to store encrypted key shares across nodes, enhancing efficiency and confidentiality. Together, these protocols shape our custom solution, combining off-chain efficiency, AI-driven automation, multi-chain compatibility, and robust, node-managed key distribution to create a future-proof, decentralized wallet system.