Hi Zcash community,
I’m Khadim, a solo developer working on OpenPGP Wallet, a non-custodial multi-chain wallet (Rust/Tauri). I’ve written a design for threshold signing of shielded ZEC in the Ironwood pool, and I’d like review from people who know FROST and the Orchard protocol well.
White paper: https://khadevs.github.io/openpgp-wallet-site/docs/OpenPGP-Wallet-FROST-Ironwood-White-Paper-v0.1.pdf
Project site: FROST — OpenPGP Wallet
The problem
The wallet is built for non-technical users: no recovery phrase to write down, a password or biometrics for daily use, and a native confirmation screen before every signature. The master entropy is encrypted with OpenPGP and backed up with Shamir 2-of-3. But to sign, the key is decrypted in RAM for a moment, and the TPM / Secure Enclave can’t sign RedPallas. As long as one device ever holds the full key, one compromised device is enough to lose the funds.
The design in short
FROST 2-of-3 per ZIP 312, with the Zcash Foundation’s re-randomized crates: share 1 on the computer (Windows, macOS or Linux), share 2 on the phone (iOS or Android), share 3 as an encrypted offline backup.
A new Ironwood account created by DKG, independent of the wallet’s seed, so stealing the seed doesn’t bypass FROST.
Signing over an end-to-end encrypted channel carried by three QR codes, no server: the phone commits first; the computer derives each α from both commitments, builds the PCZT (ZIP 374) and signs its share; the phone decodes and checks the transaction and the computer’s share itself, then co-signs; the computer finishes.
The phone follows the ZIP 374 signer checks (nullifiers against the FVK, cmx against recipient/value/rseed, user_address against recipient) and refuses redacted PCZTs.
I know FROST shielded multisig already exists (Zkool, zcash-sign). The goal here is the product: a consumer wallet where the second signer is simply the user’s own phone.
Decisions I’d like challenged
Viewing key. Testnet uses the FVK construction zcash-sign uses today; the mainnet account waits for zcash/zips#895 and ZIP 2005, so no user holds funds in an account without quantum recoverability. Is that the right call?
Backup share at setup. The phone runs the backup participant’s DKG role and holds two shares for one setup, in RAM only, before encrypting share 3 and wiping it. Users can use a spare device instead. Is there a better option without a third device?
Nonces never stored. Three QR codes rather than pre-generated commitments, to rule out nonce replay after a phone backup restore. Reasonable trade-off?
Randomizer. Until zcash/orchard#571 lands, the builder picks α and signers use the external-randomizer path (ZcashFoundation/frost#1094). Any concern with this interim approach?
Scope and transparency
100% non-custodial: no server, no coordinator run by me, every share belongs to the user.
The first networks targeted are shielded ZEC, Solana, NEAR, Stellar and Bitcoin (Taproot addresses): all use Schnorr-type signatures, the kind FROST produces. This work covers shielded ZEC; the same architecture extends to the other networks, to Cardano and to Solana tokens (such as the Solana versions of USDC, USDT and EURC), and more generally to any chain whose signatures match a standard FROST ciphersuite, such as Ed25519 or BIP-340 Schnorr; those extensions will be funded separately. Ethereum and compatible networks, Tron, XRP and Dogecoin sign differently (ECDSA, as the wallet’s accounts on those networks do): they need another, heavier family of protocols, considered later. Monero, transparent ZEC and non-Taproot Bitcoin cannot use FROST either.
Code will be published open source in the coming weeks. Nothing has been audited by an independent firm yet.
I plan to apply to Zcash Community Grants for this work, in a separate thread, after collecting feedback here.
Critical feedback very welcome. Thanks for reading!