Recoverian Network
A network concept developed by an independent organization to support key recovery for non-custodial wallets. UPBOND cannot restore users’ keys—key recovery is handled by independent “recovery agents.”
The ideal scenario for a non-custodial wallet is that only the user can manage their own keys. However, the flip side of this is that if you lose your keys, you lose your assets. By design, UPBOND cannot recover users’ keys.
That is precisely why it is not UPBOND that supports recovery, but independent “ Recoverians.” The Recoverian Network —a network of multiple independent organizations—provides users with the ability to recover their keys while maintaining non-custodial security.
The Biggest Challenge for Non-Custodial Services
The biggest challenge with self-custody is the loss of keys. However, if the wallet provider itself controls the recovery process, that becomes “custody”—closer to traditional custody. Recoverian resolves this dilemma through its design.
If you lose your keys, you'll lose your assets.
With self-custody, the moment you lose your seed phrase or device, you lose access to your assets. The lack of a recovery method is a major barrier to entry for users.
If the service provider is in charge of the restoration, the funds will be held in escrow.
If service providers were to retain the means for recovery themselves, they would effectively be managing users' assets, which would undermine the premise of non-custodial service.
Entrust the recovery efforts to an independent body
An independent third-party organization —neither the service provider nor UPBOND—holds the key that enables recovery. This structure inherently balances non-custodial security with recoverability.
Divide roles, not keys
Based on technology disclosed in an internationally published patent application, information related to key recovery is divided among three parties. No single party can restore the user’s key on its own.
| The parties involved | Items to Keep | Items Not Retained |
|---|---|---|
| User Device | Device Share (Sharing on the Device) | — |
| UPBOND | Only the encrypted recovery information (ciphertext) | I do not have the decryption key |
| Recoveryan | Decryption Key Only | We do not hold ciphertext or users' private keys |
The decryption function is not hosted on the wallet provider’s servers. UPBOND merely holds the ciphertext and does not possess the decryption key, while the recoverer holds only the decryption key and does not possess the ciphertext. This separation is the very essence of non-custodial storage.
Recavarian never holds users’ private keys or assets under any circumstances. Recavarian retains only the decryption keys generated under its own control . Wallet restoration is completed entirely on the user’s own device.
Reasons for Forming a Network Rather Than a Single Organization
User recovery information is individually wrapped using multi-recipient encryption (envelope encryption, based on HPKE / RFC 9180) with the public keys of each participating organization. This structure, which is not dependent on any single organization, safeguards users’ ability to recover their data.
Support can be provided by any one of the organizations (any-of-N)
Recovery information is individually encrypted using the public keys of each participating organization, allowing any single organization to assist with recovery.
1. Resilient against the withdrawal or failure of a single institution
Even if one institution withdraws or experiences an outage, other institutions will cover for it, so users' ability to recover will not be compromised.
Newly Participating Organizations Also Cover Existing Users
Organizations that join later can also participate in the recovery of existing users through a controlled re-wrapping procedure.
Could be expanded to k-of-n in the future
The design also anticipates the future development of a k-of-n scheme requiring coordination among multiple organizations.
Four Design Principles That Underpin the Network
This is a principle designed to consistently safeguard users’ non-custodial status and recoverability, even as the number of participating institutions increases.
Private keys are not transferred between organizations.
Each organization generates and stores its key pairs within its own HSM, and the private keys never travel over the network.
UPBOND cannot be involved in decryption
We will permanently maintain a structure in which wallet providers cannot be involved in the decryption process in any way.
Do not re-encrypt upon joining or leaving
An institution's participation or withdrawal does not require re-encryption of the ciphertext; it is completed solely by appending or deleting a wrap.
All decryption is auditable
All decryption operations are recorded and carried out as a controlled and auditable process.
Roles Expected of a Recoverian
No large-scale infrastructure investment is required. We are looking for independent institutions capable of ensuring business continuity—such as trust banks, financial institutions, auditing firms, and law firms.
Secure Storage of Key Pairs
Safely store the decryption key pair under your own control (use of an HSM is recommended).
Controlled Response to a Decryption Request
We respond to decryption requests from users in accordance with a controlled process.
Cooperation with Audits
We maintain records of decryption operations and assist in the operation of an auditable process.
Participation risks are mitigated by the structure.
We address head-on the concerns held by organizations considering participation. Many risks are mitigated not by operational efforts, but by the network design itself.
Wouldn't that mean we'd be holding users' private keys and assets?
We do not store any of these. We retain only the decryption keys generated under our own control; we do not store users’ private keys, assets, or ciphertext. The decryption process is completed entirely on the user’s device.
Wouldn't that put them in a position where they could access user assets on their own?
This is structurally impossible. The decryption key alone cannot be used to decrypt anything (the ciphertext is stored on the UPBOND side, and the Recoverian does not retain it). The system is designed so that no single party can access the user’s key on its own.
Wouldn't a leak of our company's keys lead to a major incident?
The impact is limited, and the key can be revoked immediately. A leaked decryption key alone cannot decrypt ciphertext without the corresponding ciphertext, and the key can be revoked immediately by deleting the wrap (encryption data key) for the relevant organization. Key rotation can also be completed without having to re-encrypt the entire ciphertext.
Could our company's failure or withdrawal directly result in the loss of user assets?
This is an "any-of-N" redundant structure. Since multiple independent organizations can each provide recovery support, the failure or withdrawal of a single organization does not create a single point of failure for the entire network. Withdrawal can be completed simply by removing the wrap.
Won't this require large-scale system investments and a dedicated organization?
This is not required. The only requirements are the secure storage of the key pair (HSM recommended), responding to controlled decryption requests, and cooperating with audits.
The risk of complying with a fraudulent decryption request is
All decryption is performed based on a request from the user and is carried out as a controlled, documented, and auditable process.
Why not join the Recoverian Network?
Companies and organizations interested in joining the Recoverian Network are welcome to contact us. We will provide personalized guidance, starting with an explanation of the roles and requirements.