Challenges we encountered:

1. Lack of wallet connection methods compatible with multisignature flows.
Current Zcash wallets do not provide connection interfaces suitable for multisig. We plan to collaborate with Zashi, YWallet, Trezor, and Ledger to introduce proper multisignature support and connection mechanisms.

2. Limitations in the MetaMask Zcash Snap.
The existing implementation does not support multisignature transaction flows, authorization message signatures, or public key retrieval. We forked the Snap, added the required functionality, and submitted a pull request to the original repository.

3. Shielded transactions are incompatible with standard multisig.
Native Zcash multisig cannot operate with shielded transactions, so we implemented the initial version of a FROST-based multisignature scheme to enable shielded flows.

4. No RPC providers exposing balance data.
Public RPC endpoints do not return balance information, so we had to run our own Zcash nodes.

FROST multisig architecture (WIP) is done through the same MetaMask snap, in the future a separate app/extension will be created to support the logic.

1. frost-jubjub WASM inside the Snap

• The FROST implementation is compiled to WebAssembly with the

  wasm

  feature enabled and exposes binding functions for DKG, address data, and signing.
• The MetaMask Snap loads this WASM bundle during startup and exposes JSON-RPC methods (frost DKG rounds, shielded address generation, PCZT signing, etc.).
• Each handler validates parameters, delegates to WASM, and keeps sensitive outputs (such as secret packages or key shares) within the Snap sandbox. Only non-secret artifacts (hex packages, verifying shares, public keys) are handed back to the UI.

2. Distributed Key Generation flow

1. Lobby/session coordination. The frontend DKG UI communicates with a lightweight coordinator service. That server merely relays Round‑1 and Round‑2 payloads between participants and never sees any private data.
2. Snap calls per round.
   • Round 1: The UI invokes the first DKG RPC. The Snap stores the participant’s secret context, returns only the public package for broadcasting.
   • Round 2: After the UI collects all Round‑1 messages, it calls the second RPC. The Snap computes the per-recipient commitments and again exposes only the ciphertexts that have to be delivered to peers.
   • Round 3: When Round‑2 data is gathered, the third RPC finalizes the key material. The Snap emits the aggregated group public key plus verifying shares, while each participant’s key share remains stored inside the Snap.
3. Address material. Once the group key exists, the UI requests shielded address metadata (ak/nk/ovk) via another RPC. This derives Sapling address components consistent with the new multisig.

3. Multisig transaction signing (shielded)

1. Wallet bootstrap. A dedicated frontend wallet layer initializes the Zcash WASM wallet, restores it from local storage, and—if needed—creates a new shielded account by requesting a viewing key, birthday block, and seed fingerprint from the Snap.
2. PCZT creation. After the wallet is synced with a lightwalletd endpoint, it produces a Partially Constructed Zcash Transaction (PCZT) for the desired recipient/amount.
3. FROST signing via Snap.
   • The unsigned PCZT bytes are sent to the Snap’s signing RPC.
   • Inside the Snap, the FROST share obtained during DKG is loaded and used to sign the Schnorr statement over Jubjub. Private keys never leave MetaMask.
   • The UI receives only the signed PCZT bytes.
4. Proofs and broadcasting. The wallet layer generates Sapling proofs for the signed transaction and submits it to the network. After broadcasting, the local wallet re-syncs and persists its database snapshot.

This architecture lets every signer retain custody via MetaMask while the web client coordinates DKG rounds, assembles transactions, and relies on the Snap as a secure signer for both key generation and shielded multisig signatures.