# ZIP 305: Best Practices for Hardware Wallets supporting Sapling

Status: Reserved

Owners: Daira-Emma Hopwood

Snapshot: a34cfc091434275120ff017c92c3b50d3cef623a

Source date: 2026-10-16T02:56:04+01:00

[Source revision](https://github.com/zcash/zips/commit/a34cfc091434275120ff017c92c3b50d3cef623a)

[Official source](https://zips.z.cash/zip-0305) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-0305.rst) · [Discussion](https://github.com/zcash/zips/issues/346)

Document how a hardware wallet (that has a trusted path to the user) should construct or verify transactions in order to protect its user, as far as possible, against attacks from the untrusted computer.

In the general case we have a hardware wallet, an untrusted computer, a delegated prover, a user, and a network connection, something like this:

```
             network
                ↕
h/w wallet ↔ computer ↔ prover
      ⤡       ⤢
         user
```

The h/w wallet should not trust the computer or the prover with spend authority, and should not allow a transaction confirmed by the user on the wallet's UI to be malleated while remaining valid. Similarly the computer should not trust the prover with spend authority (this is automatic when the computer is not trusted with that authority), or ability to malleate the intended transaction.

We believe that the Sapling design supports this without requiring the h/w wallet to be able to either prove or verify Spend or Output proofs. A h/w wallet should only need to implement:

- Pedersen commitments using Jubjub arithmetic (for note and value commitments)

- BLAKE2b and BLAKE2s (and the various PRFs / CRHs they are used in)

- Nullifier check (using Jubjub arithmetic)

- KDF plus either encryption or decryption (AEAD_CHACHA20_POLY1305)

- SignatureHash algorithm

- Signatures (RedJubjub, i.e. randomized EdDSA on the Jubjub curve)

- A source of randomness.

## Citation relationships

Cites: None

Cited by: None