Feature request: Decoy PIN that unlocks a separate wallet

# Feature request: Decoy PIN that unlocks a separate wallet

I would like to propose a new **Decoy PIN** feature for Jade.

This would **not replace or modify the existing Duress PIN**. It would be an additional security feature.

## Summary

The idea is to have **three separate PIN behaviors**:

* **Normal PIN** → unlocks the real wallet.
* **Duress PIN** → keeps the existing Jade behavior, erasing the encrypted wallet data.
* **Decoy PIN** → new feature that unlocks a different, believable wallet.

## Goal

The concept would be simple:

**Normal PIN → real wallet**

**Duress PIN → erase encrypted wallet data**

**Decoy PIN → decoy wallet**

Entering the Decoy PIN should unlock Jade normally, except that Jade would load a completely different wallet.

Ideally, from the user's perspective and from the perspective of someone observing the device, the decoy wallet should behave exactly like a normal Jade wallet.

It could contain a small amount of bitcoin and have normal transaction history, making it a usable and believable wallet rather than producing an error or wiping the device.

## Ideally, the wallets should be independent

My preferred implementation would use a **completely separate seed** for the decoy wallet.

I would prefer not to implement this as simply another BIP39 passphrase wallet derived from the real recovery phrase.

The goal should be to minimize shared secret material and shared failure modes between the real and decoy wallets.

Conceptually:

```text
Real PIN
↓
Encrypted real wallet
↓
Seed A

Decoy PIN
↓
Encrypted decoy wallet
↓
Seed B
```

Seed A and Seed B would ideally be unrelated.

Compromising the decoy wallet should provide no useful information about the real wallet.

The two PINs should effectively unlock two independent encrypted wallet slots.

## The backup problem

The obvious disadvantage is backup complexity.

If Jade simply generates a second independent BIP39 mnemonic for the decoy wallet, the user now needs to maintain:

* Real wallet recovery phrase
* Decoy wallet recovery phrase

That creates another OPSEC problem.

Someone could lose one backup, confuse the two recovery phrases, or eventually forget which one represents the real wallet and which one represents the decoy wallet.

So I think it would be interesting to investigate whether Jade could provide the security properties of a separate decoy wallet while minimizing the additional backup burden.

## Possible BIP85 alternative

Jade already supports BIP85 child recovery phrases.

One possible compromise could therefore be:

1. Start with the real recovery phrase.
2. During Decoy PIN setup, derive a BIP85 child recovery phrase at a defined index.
3. Store the resulting child seed as a separate encrypted wallet on Jade.
4. Protect that wallet independently with the Decoy PIN.
5. After setup, unlocking the decoy wallet should require access only to the separately encrypted child seed, not the real seed.

The advantage is that the user would not necessarily need another 12/24-word backup. The decoy wallet could be regenerated from the real recovery phrase plus the BIP85 index.

I understand that this would **not** make the two seeds cryptographically independent. It would therefore be different from the preferred two-independent-seed design.

However, BIP85 is designed so that disclosure of a child recovery phrase does not reveal the parent recovery phrase, so perhaps this could provide an interesting tradeoff between wallet separation and backup simplicity.

I would be interested in the developers' opinion about whether this is appropriate for a decoy-wallet threat model.

## Security properties

If technically possible, I think a Decoy PIN should aim for the following properties:

* The existing Duress PIN behavior remains unchanged.
* The normal PIN and Decoy PIN are both valid unlock PINs.
* The normal PIN unlocks the real wallet.
* The Duress PIN erases the encrypted wallet data as it does today.
* The Decoy PIN unlocks a different wallet.
* Entering the Decoy PIN does not erase the device.
* The decoy session looks and behaves like a normal Jade session.
* The UI should not indicate that the wallet is a decoy.
* The real wallet should not become accessible from the decoy session.
* The decoy wallet should not expose the real wallet's xpub, fingerprint, addresses, seed, or other wallet-specific information.
* Unlock timing and behavior should ideally not make it obvious whether the normal PIN or Decoy PIN was used.
* If separate encrypted wallet slots are used, compromising the decoy slot should not compromise the encryption of the real wallet.

The interaction with Jade's Blind Oracle/PIN lockout system would obviously also need careful consideration.

## Hardware / firmware feasibility

I do not know enough about Jade's hardware and firmware architecture to know whether securely maintaining two independently encrypted wallet slots is practical.

Jade already stores encrypted wallet key material and supports BIP85-derived child recovery phrases, so it seems that some of the required building blocks may already exist.

However, supporting two valid PINs that unlock two separate encrypted wallets may introduce security, storage, oracle, and state-management issues that I am not considering.

I would especially like feedback from the Jade developers on this part.

The priority should be security rather than implementing a decoy feature if the architecture cannot support it cleanly.

## Why I think this could be useful

The existing Duress PIN and the proposed Decoy PIN address different threat models.

The current Duress PIN can protect the wallet by erasing the encrypted wallet information on Jade.

The Decoy PIN would address a different situation: coercion where the attacker expects the device to successfully unlock and expects to see a functioning Bitcoin wallet.

So Jade could offer three distinct responses:

```text
Normal PIN → real wallet

Duress PIN → encrypted wallet data erased

Decoy PIN → Jade unlocks normally → believable secondary wallet
```

This would not provide guaranteed plausible deniability against every attacker, especially an attacker who already knows Jade supports the feature.

But I think it could be a useful additional security option alongside the existing Duress PIN.

I would be interested to know whether the current Jade hardware and Blind Oracle architecture could support something like this securely.

---

Coldcard has offered a decoy PIN feature in the past. I am not familiar with the technical details of its implementation, but the general concept is interesting and may be worth evaluating for Jade.

Even if the two devices have very different security architectures and design choices, some individual features from other hardware wallets can still provide useful ideas for consideration.

No files, tests, or entry points are identified in the issue. Start by mapping Jade's PIN handling, encrypted wallet storage, Blind Oracle lockout behavior, and BIP85 support, then determine whether the requested independent wallet behavior can meet the stated security properties without changing the existing Duress PIN behavior.

Written by the indexing model from the issue text.