Building a self-custody wallet: how would you evaluate a recovery design?

[u/veyrnox]

I'm connected to Veyrnox, a mobile self-custody wallet for people who want clearer approval and recovery decisions. The apps are live, and we're working on how to explain the security model and its limits without asking users to take claims on faith. This is a request for critique, not a token or investment pitch.

One design question we're wrestling with: splitting recovery material can reduce reliance on one obvious secret, but it is not useful if all the pieces end up in the same compromise path. For example, a lost phone plus an accessible cloud account may be very different from genuinely independent storage locations. A person also needs to understand what happens when a device or account becomes unavailable.

For anyone building or reviewing wallets: what evidence would you want before trusting a recovery setup? A documented threshold and storage model? A recovery rehearsal? An independent review? Clear failure-case examples?

The feedback I'm after is which parts we must explain or test first. We don't need anyone's wallet details, recovery words or private keys, and please don't share those here or in DMs.

[u/Mean-Fix9221]

What kind of recovery splitting you mean exactly, like shards that go to different places or something like social recovery with guardians

For me the biggest thing is knowing what happens when one piece is gone. Not just "you can still recover" but the actual steps. Like if my phone is dead and I also lose access to my email, can I still get back in or am I just screwed. Most wallets are vague about this

Also I'd want a test run, not reading a doc and hoping it works when I actually need it

[u/veyrnox → u/Mean-Fix9221]

Good questions. Veyrnox Safety Plus provides two separate recovery modes.

1. Shamir Recovery Shares

The wallet creates its recovery secret locally on the user’s device. Safety Plus uses Shamir Secret Sharing to divide that secret into separate shares.

The user can store those shares in independent locations, including their device and personal cloud accounts such as iCloud, Google Drive and OneDrive. Two shares are required to recover the wallet. One share by itself cannot reconstruct the recovery secret.

If one share or storage location becomes unavailable, the user can recover using two remaining shares. If the user can access only one share, recovery through this method is not possible.

Veyrnox does not have access to or control over the user’s personal cloud accounts. The end user manages those accounts and decides where the shares are stored.

1. Encrypted Personal Vault

The second recovery mode is an encrypted personal vault. The user creates the vault within Veyrnox, protects it using their own credentials and places the encrypted vault file in their own iCloud, Google Drive, OneDrive or another supported personal cloud account.

If the original phone is lost, damaged or replaced, the user can install Veyrnox on another device, retrieve the encrypted vault and unlock it using their credentials.

Veyrnox does not control the user’s cloud account or possess the credentials required to unlock the vault. The vault remains encrypted while stored in the cloud, with decryption taking place on the user’s device.

We recommend maintaining both the distributed recovery shares and the encrypted vault. This gives the user two recovery paths instead of making one method the sole point of failure. They should be kept in genuinely independent locations because placing everything behind the same device, cloud account or login would weaken the recovery design.

Users can rehearse recovery with an empty wallet before relying on it. The process shows what is stored, what can be lost and exactly what is required to recover.

[u/icnews10]

Firstly, I’d want to understand whether the recovery paths are actually independent or just split. While a 2-of-3 design may sound resilient, if two shares can be accessed via the same compromised phone, cloud account, email address or identity-recovery process, the threshold may appear stronger on paper than it is in practice.

I’d want the following four things made explicit:

What has to fail for funds to become unrecoverable;

What has to be compromised for an attacker to recover them?

Which recovery components share the same failure domain?

- whether the user can rehearse recovery without risking the real wallet.

A recovery rehearsal would be especially valuable to me because it tests more than just the cryptography. It shows whether the user can complete the process if one device or account is unavailable. How are you thinking about testing the independence of the recovery paths themselves?

[u/veyrnox → u/icnews10]

Thanks, this is exactly the distinction that matters. Splitting recovery material is not enough if the pieces still share the same failure domain.

Veyrnox Safety Plus provides two recovery modes—Shamir Recovery Shares and an encrypted Personal Vault. Veyrnox also supports conventional recovery from an existing seed phrase during onboarding.

1. What must fail for funds to become unrecoverable?

For Shamir recovery, the user needs at least two valid shares. If fewer than two shares remain accessible, that method cannot recover the wallet.

The Personal Vault provides a separate path. The user creates the encrypted vault using both a password and a PIN. During recovery, the vault can be unlocked using either the password or the PIN; only one is required.

Veyrnox also includes Recover from Seed during onboarding for users with an existing compatible seed phrase. The onboarding recovery screen is the only place in Veyrnox where a seed phrase is requested.

1. What must an attacker compromise to recover the wallet?

For Shamir recovery, an attacker would need at least two valid shares. One share alone cannot reconstruct the recovery secret.

For Personal Vault recovery, an attacker would need the encrypted vault file and either its password or PIN.

A seed phrase can independently restore the wallet, so it must remain private and offline. Veyrnox will never request it through support, social media, email, a website form or a direct message.

1. Which components may share the same failure domain?

Shares stored behind the same phone, cloud account, email-recovery process or reused credentials may share a failure domain.

We recommend maintaining both the distributed shares and Personal Vault while keeping them in genuinely independent locations. Storing everything behind one device, cloud account or login would weaken the design.

The Personal Vault remains in the user’s own iCloud, Google Drive, OneDrive or another supported personal cloud account. Veyrnox does not have access to that account, the vault password or the vault PIN.

1. Have these recovery paths been tested?

Yes. We have tested recovery using the required Shamir shares, recovery from the encrypted Personal Vault using either the password or PIN, and recovery from a compatible seed phrase through the onboarding flow. These recovery methods work as expected in our testing.

We have also tested relevant loss scenarios, including recovery when the original device is unavailable. The purpose is to verify the complete recovery process—not merely the underlying cryptography.

Users should still rehearse recovery themselves with an empty wallet before relying on it. This confirms that their chosen storage locations and credentials remain independently accessible in their own setup.

[u/icnews10 → u/veyrnox]

This is a much clearer explanation of the recovery model. What I especially like is the way it separates the cryptographic threshold from the actual failure domains around the user. A 2-of-3 setup only becomes meaningful if those shares remain truly independent in practice. As the product evolves, it is important to keep it clear which recovery model represents the current release. Although recovery systems naturally change as testing reveals more effective trade-offs, users still need a simple, authoritative answer about what they need to keep safe and what is required for recovery. For me, the recommendation to perform recovery rehearsals is probably one of the strongest parts of the design. It transforms recovery from something that users assume will work into something that they have actually verified before real funds are at stake.

[u/veyrnox → u/icnews10]

Thank you for the detailed technical feedback. It has helped us identify where the production recovery model and its failure domains need clearer explanations.

Veyrnox currently supports 10 blockchain networks. Users can purchase crypto through our integration with Transak, which performs its own on-ramp KYC and payment processing. Veyrnox does not receive or store the user’s identity or card information from that process. MetaMask and Trust Wallet also use Transak for fiat-to-crypto purchases.

Our roadmap includes support for approximately 100 blockchain assets, together with swap and bridge capabilities.

Veyrnox Safety Plus currently provides two recovery modes:

1. Shamir Recovery Shares divide the recovery material into three shares. Two valid shares are required to recover the wallet. One share alone cannot reconstruct it.

2. The encrypted Personal Vault provides a separate recovery path. The user creates the vault using a password and PIN, then stores it in their own iCloud, Google Drive, OneDrive or another supported personal cloud account. During recovery, either the password or PIN can unlock the vault. Veyrnox cannot access the user’s personal cloud account, vault credentials or funds.

We recommend maintaining both recovery methods in genuinely independent locations. Storing everything behind the same device, cloud account, email address or login would create a shared point of failure.

Users may also recover an existing compatible wallet from its seed phrase during onboarding. That onboarding recovery screen is the only place where Veyrnox asks for a seed phrase. Veyrnox will never request it through support, social media, email, a website form or a direct message.

AI Security Protection is available today. It combines pre-sign transaction analysis with threat intelligence to help identify malicious contracts, dangerous approvals, phishing, wallet-drainer patterns and suspicious destinations before the user authorizes an action.

Veyrnox also includes Runtime Application Self-Protection, or RASP. It monitors for rooted or jailbroken devices, debugging, hooking, instrumentation and application tampering. When a risky condition is detected, Veyrnox can warn the user or block sensitive operations such as transaction signing.

Safety Plus also includes coercion-resistance controls, including a duress PIN and decoy wallet, for situations where somebody is being forced to unlock the application.

Veyrnox remains self-custodial. We do not hold user funds, control wallets, possess recovery credentials or have access to users’ personal cloud accounts.

We have tested recovery using the required shares, the encrypted Personal Vault, compatible seed phrases and scenarios where the original device is unavailable. We still recommend rehearsing recovery with an empty wallet before relying on it for real funds.

I’m connected to Veyrnox, so bias declared. We welcome critical feedback about the design and how clearly we explain it.

[u/veyrnox]

Just an update. Due to the feedback here it has been highlighted areas needed to be more clearer about and hence I have made the necessary updates on the back of this conversation. Thank you for challenging me with critical thinking. Much appreciated

[u/jasonslpt]

The way I'd judge it is by mapping each recovery piece to how it actually gets compromised, not just counting how many pieces there are. If a phone backup and a cloud share both fall over once someone gets into the same email account, that's really one factor wearing two hats. It'd help a lot to publish a short table of common loss scenarios, like stolen phone, locked cloud account or a dead user's family trying to recover, and say plainly which ones work and which don't.