Shielded Multisig (for Halo)

Applicant background

I am a software engineer who worked for several major projects including:
Windows (OS kernel), .NET framework (compiler and code generation) and SQL
Server (Engine / query execution). I was also the CTO of startups and listed

I have completed the Cold Wallet and BTCPay Server integration grants for Zcash
and I am the primary developer for ZWallet.

Description of Problem or Opportunity

Multisignature transactions have unique use-cases not covered by regular

  • 2 of 2: Every party must sign to approve spending
  • 2 of 3: Escrow account where two counterparties can agree to spend but in case
    of a disagreement they can engage of third party.
  • n of n: High security vault

Proposed Solution

The ZF has published the FROST scheme that allows the creation of multi party
Schnorr signatures.

I propose to use it as a foundation for Zcash shielded transactions. There are
several outstanding design points to complete:

  • Derivation of the nullifier keys, viewing keys, etc in the context of a
    multisig account,
  • Encoding of multisig keys
  • The Zcash protocol rerandomizes the authorization signature. This is not
    supported in FROST yet.
  • FROST has several rounds. The exact definition of the message protocol has to
    be specified.
  • The protocol also depends on whether we have an aggregator or not.
  • Currently, signing is a regular function. Because of the multiple rounds
    involved, it needs to be refactored so that it can run in stages
  • Signers must be able to safely check that the request they receive is

Solution Format

Each of the points mentioned in the previous section must be addressed before

  • I will work with the ZF/ECC to validate and audit the design, especially
    regarding the cryptographic aspects.
  • I will write and submit ZIPs as fit,
  • I will define an API with input from the wallet owners who are interested in
    this feature
  • I will implement a library in rust for distributed key generation and
    multisignatures (client and server)
  • I will implement a (trustless) server that orchestrates the signing protocol
    and the distributed key generation
  • I will add test vectors and unit tests for both client and servers
  • I will write the documentation to help wallet owners. It remains their choice
    and responsibility to integrate.
  • I will add multisignature to ZWallet

This project is for NU-5.

Technical approach

Key Generation

Users participate in a distributed key generation protocol with assistance from
a server (hosted in the cloud or on premises). After which, they are given a
secret key share, a group viewing key and an address.

Alternatively, if they want to do everything off line, they can use a command
line tool and transmit the data manually. Due to the nature of the protocol,
this means sending a file to each other party and therefore receiving N-1 files.
Then the secret share and public key / viewing key are calculated. This is
similar to multi sig in Bitcoin which uses xprv and xpub keys to derive joint

Signing a transaction

To spend from the multisig account, the initiator wallet generates a session QR
code. He/She sends it to each co-signer who then can connect to the multisig

contacts the server passing the transaction data (inputs/outputs), encrypted for
each of the other parties. Other signers retrieve the signing request and
calculate their signature share (after confirmation from the user). The shares
are aggregated to produce the final transaction and is transmited to the
network. The server only knows the IP and the timestamp of the transaction.

How big of a problem would it be to not solve this problem?

Users can use transparent multisignatures but will not benefit from the privacy
associated with shielded transactions.

Execution risks

  • Though the low-level cryptographic protocol (FROST) is well defined and
    studied, there is a need for adaption to the Zcash protocol
  • The high-level protocol between signers needs to be designed, reviewed and
  • ZIP may take longer than expected
  • How multisignature addresses fit with UA is TBD

Unintended Consequences

  • Multisig accounts work differently than regular accounts and users need to be
    aware of it, specifically regarding the handling of their keys
  • The aggregator server must be up and running or multisig accounts will not be
    able to spend. However, a private entity can always deploy their own instance

Evaluation plan

  • Design Documentation
  • ZIP
  • API documentation
  • Implementation as a rust crate
  • Support in ZWallet

Schedule and Milestones

The project is split equally between the design and specification phase and the
implementation phase

  • M1 Design: Adaptation of FROST to zcash
  • M2 Design: Key/Share derivation and encoding
  • M3 Design: Co/Signer workflow and message protocol
  • M4 Design: Client (Wallet)/Server API
  • M5 Design: Transaction Builder for multisig
  • M6 Implementation: FROST for Zcash
  • M7 Implementation: Key Generation and utilities
  • M8 Implementation: Transaction Builder
  • M9 Implementation: Client/Server
  • M10 Integration: ZWallet


Each milestone is roughly of equal size and takes 10% of the overall budget for
a duration of ~1-2 month.

  • M1 Design: 10%
  • M2 Design: 10%
  • M3 Design: 10%
  • M4 Design: 10%
  • M5 Design: 10%
  • M6 Implementation: 10%
  • M7 Implementation: 10%
  • M8 Implementation: 10%
  • M9 Implementation: 10%
  • M10 Integration: 10%

Very exciting proposal @hanh . Good luck!

1 Like

Multisig shielded is a very foundational technique for the widespread, and especially institutional level, adoption of Zcash.

From what I can tell, Hanh is a very competent engineer. My main concern would be to establish a clear line of communication and working relationship with other Zcash core devs that may be working on things around this problem as well. It would be good to have one of these devs vouch that they have seen this proposal and would be able to act as an advisor or resource for this work.

Also, although it is unreasonable to request that Hanh assist in every different wallet integration, sometimes documentation can only go so far. So it would be good to know if Hanh would be willing to respond to reasonable requests for advice from other wallet devs when they implement multisig in their own software.

Best of luck


@hanh I like the number of milestones :+1:.

At a high level it looks like a good idea. Given this looks to be a really large grant we just need to make sure expectations for each milestone are clearly documented. All the normal stuff :slightly_smiling_face:.

1 Like

@David_Heisenberg @GGuy Indeed, a big part of the job is to work out everything between the various stakeholders: ECC, ZF and wallet developers. From M1 to M5 (half of the project) is about design, specifications, documentation, API, and planning. In fact, I think several ZIPs will have to be written.


Having a multisig implemented for Zcash opens up so many more product opportunity. From robust legacy/inheritance product, community fund management to social recovery wallet. Hard yes from me.

1 Like

@hanh has been delivering great results for Zcash, and based on what I’m seeing the work seems to be consistently of a high standard.

Coupled with this, shielded multisig will be a very useful feature that as others have mentioned will be necesaary for many interesting applications.

Thumbs up from me on this one.

1 Like

@hanh Thank you for submitting your Shielded (Multisig for Halo) proposal, below please find the @ZcashGrants committee response:

"After speaking with the engineering teams at ECC and ZF, the ZCG Committee has decided to reject Hanh’s grant at this time. Instead, the Committee requests that Hanh wait until the FROST specification is complete, the proof for re-randomizable FROST is written, and the ZIP for re-randomizable FROST written, which are expected to be completed in Summer 2022. The scope of Hanh’s proposal should be limited to integrating FROST implementations into existing wallets. Before resubmitting his grant proposal, the Committee requests that Hanh reach out to the engineering teams at ZF and ECC (via the biweekly Arborist calls or Discord Zcash R&D channel) for their feedback and guidance.

In the meantime, we ask that Hanh consider submitting a separate proposal to work with Zcash core developers to push the Pedersen hash syncing mechanism upstream via librustzcash to help other wallets in the Zcash ecosystem achieve fast syncing times."


I’m going to object to this statement. (Not that it will change anything).

In my opinion, Hanh’s follow-up proposal should include whatever he feels is necessary to safely implement FROST. It’s a proposal. If you are rejecting his initial proposal, then you shouldn’t project bias and foregone conclusions on a future proposal (especially when ECC/ZF claim to not even be done with the spec yet!!). For example, what if the Zcash community is smart enough to enlist Hanh in formally reviewing the spec slated to be completed by ECC/ZF engineers “summer 2022”?? The point is you should review his new proposal after it’s submitted. And I applaud his initial proposal for including design phase, specification phase, and implementation phase.

I find it disheartening that Hanh is being told to “wait” instead of allowing for further collaboration for the specification phase. The messaging to devs is a bit off-putting and has a “not built here” vibe; if Zcash entities aren’t more inclusive in this regard, then talented devs like Hanh are going to go elsewhere.

I was hoping for a better outcome on this proposal; I think this was a missed opportunity to do the right thing. But since the decision has been made, I felt it was important to mention that we shouldn’t make the mistake of telling Hanh today what he should put in future proposals.


I agree with you. It looks strange that this got turned down given hanh’s back record.
I use WarpWallet because of it’s very fast syncing, and integration of snap addresses. I believe it is one of the better alternatives and yet it is not on the Wallets - Zcash list.
No mention either of the wordpress add-on to receive sec via btcpayserver.

Why not putting more light on that previous work?

I hope you’ll be continuing to contribute, hanh.

Could this be an opportunity to try funding an individual rather than a specific project?

I really like Zwallet and want to see what else @hanh can come up with for Zcash. He has a track record of delivering.

1 Like

I think individuals have received research grants before. But for delivering production GA apps… that’d be new precedent I think.

The thing I liked about the initial proposal was that it articulated intent for an independent contributor (Hanh) to collaborate with the core central ECC/ZF devs…. To produce a value-adding application.