Web3 is expanding rapidly: new applications, protocols, and features emerge daily. However, for many users, the true barrier to entry is not a lack of on-chain functionality, but rather the challenge of securely safeguarding and recovering wallet keys.
Currently, the industry standard remains the seed phrase (mnemonic). Yet, this approach presents real-world challenges: users often screenshot their phrases, inadvertently syncing them to cloud albums; others write them on paper only to have them lost or damaged, resulting in the permanent loss of assets. Such stories are all too common. Often, these risks stem not from technical failures, but from lapses in daily habits.
In recent years, an increasing number of "Web2-style" wallet solutions have emerged, allowing users to create, back up, and recover wallets using familiar login methods. While their goal is to lower the barrier to entry, there are significant differences in how they are implemented—specifically, whether they remain truly decentralized and self-custodial.
The Risk of Centralized Sharding: Some solutions split the private key into multiple "shares" or "shards." The splitting itself is not the issue. The critical risk arises if a single participating entity (such as the service provider's backend) holds enough shares to meet the recovery threshold. If they do, they technically possess the ability to reconstruct the complete key, rendering "self-custody" merely a nominal promise.
The Risk of HSM Dependencies: Other solutions store private keys within Hardware Security Modules (HSMs), claiming they will only sign transactions according to strict rules. While this sounds sound, if the rule enforcement or policy execution occurs outside the trusted boundary (i.e., external to the HSM), it can—in extreme scenarios—be bypassed or manipulated, resulting in signatures that do not reflect the user's intent.
How OneKey Keyless Wallet is Different
OneKey’s Keyless Wallet utilizes a "Google/Apple Login + PIN" approach, integrating ease of use with true self-custody in a single design.
You perform login and recovery using familiar account systems, but the underlying architecture employs a distributed key management and signing mechanism. This ensures that no single party—including OneKey—can reconstruct your complete key or unilaterally initiate transfers.
In other words: even if our servers, a specific component, or a single participating entity were compromised, an attacker could not simply breach OneKey to "steal your wallet."
OneKey’s Solution
OneKey's Keyless Wallet is built on a distributed key management mechanism. Its goal is to liberate you from the high-risk burden of writing down, storing, and transporting seed phrases. Instead, you can create and recover your wallet using a method you already know: Google / Apple Login + PIN.
Reduced Burden, Uncompromised Self-Custody
Traditional wallets rely on seed phrases (typically 12 or 24 words), requiring users to securely store and manually restore them when needed. Keyless Wallet allows you to manage your assets by simply remembering a PIN. The ability to recover your wallet is built upon a distributed architecture, ensuring that full control is never handed over to any single service provider.
Dual Authentication: Account + PIN
The Keyless Wallet utilizes two authentication factors:
Your Google / Apple Account
Your PIN
This means that even if your Google or Apple account is compromised, critical operations cannot be performed without the PIN. Conversely, having the PIN alone is insufficient to recover or access the wallet without logging into the associated account. Both factors are indispensable, significantly reducing the risk of a single point of failure.
The Seed Phrase Reappears Only After Verification
In the Keyless Wallet design, the complete seed phrase or private key is never stored in plain text in any single location for extended periods. It is only when you successfully verify both your account and PIN on your device that the wallet completes the necessary recovery and activation processes locally.
How Backup and Recovery Works:
Encrypted Storage: Data related to the seed phrase is stored on the server in an encrypted form to ensure availability (e.g., for cross-device recovery).
Sharding Mechanism: The critical materials required for decryption are split and distributed across multiple parties or nodes.
Therefore, unless you complete the verification and trigger the recovery on your device, no single party (including OneKey) can unilaterally reconstruct it into a usable plain-text key.
Technical Deep Dive
This section explains what happens on both the client side (your device) and the server side when you create a new Keyless Wallet using Google or Apple. It also clarifies why the "Backup" and "Recovery" processes are user-friendly while ensuring that no single party can ever access your complete private key.
Backing Up a Keyless Wallet
When creating a Keyless Wallet during the onboarding process, you can:
Select "Continue with Google" on the home screen.
Or tap the "•••" button → Keyless Wallet → Select Google or Apple.
Important Note: The Keyless Wallet and traditional seed phrase wallets are two distinct, independent systems. Currently, migrating an "existing seed phrase wallet" to a Keyless Wallet is not supported; they exist in parallel.
Let’s walk through the technical process that occurs when a user creates a wallet using their Google or Apple account.
Step 1 — Generating, Encrypting, and Storing the Seed Ciphertext on the Device
Local Generation: The device locally generates a new seed phrase (serving as the random source for the wallet's key material).
Symmetric Key Creation: The device simultaneously generates a Symmetric Key.
Encryption: The device uses this Symmetric Key to encrypt the seed phrase, producing the Seed Ciphertext.
Secure Storage: Only the Seed Ciphertext is transmitted to the OneKey backend for secure storage (ensuring availability for cross-device recovery).
Key Points:
Local-Only Processing: Both the plaintext seed phrase and the Symmetric Key are generated and processed exclusively on the device. They are never directly transmitted off the device.
Unusable Ciphertext: The ciphertext itself cannot be used for signing. Without the Symmetric Key, it is impossible to decrypt the ciphertext back into a usable seed phrase or key material.
Step 2 — Splitting the Symmetric Key into Two "2-of-2" Shares
Back on the device, the Symmetric Key is split into two shares using Shamir's Secret Sharing (SSS) with a 2-of-2 threshold:
Backend Share: Held by the OneKey backend.
Juicebox Share: Stored within the decentralized storage protocol, Juicebox.
Key Points:
Under a 2-of-2 threshold, no single share is sufficient to reconstruct the Symmetric Key. Even if OneKey possesses both the "Seed Ciphertext" and the "Backend Share," it cannot unilaterally recover the wallet or initiate a transaction signature.
Step 3 — Writing the Network Share to the Distributed Network, Protected by PIN
The Juicebox Share is written to the Juicebox network.
The user sets a PIN, which serves to protect access for retrieving this share from Juicebox.
Technical Implementation: The share is further split into multiple Sub-shares and distributed across different nodes for storage. To retrieve the share, the correct PIN must be entered to pass the network's threshold verification.
Recovering a Keyless Wallet
Step 1 — Authentication and Retrieving the Seed Ciphertext + Backend Share
The device performs authentication using your Google / Apple account.
Upon successful verification, the device retrieves two pieces of data from the OneKey backend:
Seed Ciphertext
Backend Share
Step 2 — Entering PIN to Retrieve the Juicebox Share
You enter your PIN on the device.
The device uses the PIN to retrieve the Juicebox Share from the Juicebox distributed storage protocol.
Step 3 — Reconstructing the Symmetric Key and Decryption
The device combines the Backend Share + Juicebox Share to reconstruct the original Symmetric Key.
It uses this Symmetric Key to decrypt the Seed Ciphertext, restoring the original seed phrase locally on the device.
Once recovery is complete, the wallet functions normally within the OneKey App, just like a standard wallet.
Comprehensive Analysis
Final State (Data Distribution)
User: Has access to their Google / Apple account and remembers the PIN.
OneKey Client (Device): Possesses the usable, decrypted seed phrase (temporarily for usage).
OneKey Server: Stores the Ciphertext and the Backend Share.
Juicebox Realms: Individually store the Juicebox Sub-shares (required to reconstruct the Juicebox Share).
Security Properties
OneKey Server Database Compromise: Even if an attacker gains access to both the Ciphertext and the Backend Share, they cannot unilaterally reconstruct the Symmetric Key. Therefore, it is impossible for them to decrypt the seed phrase.
Compromised Juicebox Realms/Nodes: As long as an attacker does not obtain a sufficient number of Juicebox Sub-shares (failing to meet the recovery threshold), they cannot restore the Juicebox Share, and thus cannot assist in reconstructing the Symmetric Key.
Account Compromise: Access to the Google or Apple account alone is insufficient to retrieve the Juicebox Sub-shares from the Juicebox side. The retrieval process is strictly protected by the PIN; without the PIN, the recovery chain cannot be completed.
Security
The design goal of the OneKey Keyless Wallet is to minimize the barrier to entry without centralizing "control" in the hands of any single party. Since wallet recovery is one of the most sensitive operations, we place the protocol's security boundaries and threat models at the core of our design. This ensures that improved usability does not come at the expense of security.
Security Goals
Our architecture is designed to meet the following two critical objectives:
No Unilateral Access: No third party (including OneKey) should be able to unilaterally reconstruct or use the user's private key or seed phrase.
Strict Recovery Conditions: The only way for a user to recover their wallet is by simultaneously satisfying two verification requirements:
Successfully authenticating via their Google / Apple account;
And proving possession of the PIN.
Why OneKey (Unilaterally) Cannot Reconstruct Your Key
To restore a usable seed phrase or key material on your device, all of the following elements must be present simultaneously:
The Seed Ciphertext
Both shares of the Symmetric Key (Backend Share + Juicebox Share)
This architecture leads to several direct conclusions:
Malicious Actors within Juicebox: If fewer than the threshold number of Juicebox Realms/nodes act maliciously, the attacker cannot reconstruct a valid Juicebox Share and, therefore, cannot reconstruct the Symmetric Key.
Total Compromise of Distributed Network: Even in the hypothetical scenario where the entire distributed sharding network is compromised, the attacker would still lack the Backend Share or the Ciphertext held by OneKey’s backend, making independent recovery impossible.
Compromise of OneKey Backend: Even if the OneKey backend were attacked, the attacker would still lack the share stored on the Juicebox side. Without the Juicebox Share, backend data alone is insufficient to reconstruct the Symmetric Key or decrypt the Seed Ciphertext.
Why "Account + PIN" Are Both Indispensable
Regarding identity and access control, the Keyless Wallet separates "Who you are" (Account Identity) from "What you know" (PIN):
The Account Side: OneKey uses established OAuth 2.0 login/authorization flows to interface with Google and Apple for identity verification and authorization.
The PIN Side: The PIN protects the process of retrieving the critical share from the distributed storage protocol (Juicebox). Even if an attacker compromises your account, they cannot retrieve the corresponding share or complete the recovery without knowing the PIN.
Encryption and Key Management
At the encryption and key splitting level, the Keyless Wallet adheres to the principle that "Ciphertext can be stored, but Keys must never be centralized":
Seed Phrase Encryption: The seed phrase/key material is encrypted using authenticated encryption algorithms (AES-256) to generate the ciphertext, ensuring integrity verification during recovery.
Key Splitting and Reconstruction: Shamir's Secret Sharing (SSS) is used to split and reconstruct the Symmetric Key according to threshold rules.
Backend Encryption at Rest: Shares stored on the backend are first encrypted using Cloud KMS and encryption algorithms before storage. This ensures that no plain text is ever visible throughout the entire process, guaranteeing the security of the key data.
Reliability
A critical point to understand about the OneKey Keyless Wallet is that recovery relies on meeting two conditions simultaneously: you must be able to log in to the corresponding Google or Apple account, and you must remember your PIN.
Unlike traditional Web2 "Forgot Password" flows, OneKey cannot retrieve your PIN for you, nor can we reconstruct your private key or seed phrase on your behalf. This is not a product defect, but a deliberate part of the security boundary: if a service provider had the ability to access any of these elements, the core attribute of "self-custody" would be fundamentally compromised.
Therefore, a true "Zero Trust" solution inevitably requires the user to bear a portion of the responsibility: maintain access to your account and remember your PIN.
What if I Forget My PIN?
However, there is a safety net: the seed phrase for a Keyless Wallet exists in a usable form on devices where you are already logged in.
If you forget your PIN but still have access to a device where the wallet is logged in and functioning, you can typically reset the PIN on that device. This process will create a new backup configuration, ensuring you retain the ability to recover across devices in the future.
Periodic PIN Verification Reminders
To mitigate the risk of forgetting your PIN over time, OneKey will prompt you to verify your PIN at appropriate intervals.
If, during one of these checks, you realize you cannot recall your PIN, you should take the opportunity to reset your PIN immediately while you still have access to the device, and then regenerate/update your backup configuration.
The Ultimate Boundary of Availability
In summary, you will generally retain access to your Keyless Wallet as long as you meet at least one of the following conditions:
You still possess a functional, logged-in device; OR
You can log in to your Google / Apple account AND you remember your PIN (allowing you to recover on a new device).
Our Recommendation: Perform a "Cross-Device Recovery Drill"
Since the recovery process is essentially just "Log in to Account + Enter PIN," we strongly recommend that you perform a recovery drill on a second device immediately after creating your Keyless Wallet.
By doing so, you will secure:
An access point on Device A.
An access point on Device B.
Verified confidence in your backup path (Account + PIN) for future recovery on new devices.
Conclusion
For many new users, while seed phrases are the industry standard, using them is often far from intuitive. Entering a seed phrase on a new device involves significant friction, and knowing how or where to store it safely is a frequent source of confusion.
The OneKey Keyless Wallet aims to strike a different balance:
It lowers the barrier to entry by using a familiar method (Google / Apple + PIN). At the same time, through a distributed key management architecture, it ensures that no single party (including OneKey) can unilaterally reconstruct your complete key. This achieves a compromise between "ease of use" and the "boundaries of self-custodial security" that is highly suitable for the general public.