ZF FROST Wallet Integration

Hi Folks,

Blockchain Commons has put forth a proposal to provide wallet integration for the ZF FROST libraries (https://frost.zfnd.org/), starting with VSS, highlighting Zcash’s role as a leader pushing forward the whole digital-asset community.

Here’s our gallery view of the proposal:

The project is laid out in six phases, so that we could initially work toward less than the whole project, if desired. To support strong integration of ZF FROST and its VSS capabilities into third-party wallets would require advancement through at least Phase Three. Additional Phases continue to improve standardization (Four, Six) and developer support (Five, Six)

We had a bit of a delay between submission of this proposal (in late January) and this posting due to forum permissions(!), which would push back the initial phase deadlines by that same amount.


ZF FROST Wallet Integration

Applicant name:

Blockchain Commons

Team member names:

Christopher Allen

Wolf McNally

Shannon Appelcline

Pitch: A one-liner elevator pitch version of your proposal

Encourage usage of ZF FROST and expand its reach through interoperability with other standards and projects.

Total Request (USD):

$157600.00 USD

Have you previously received a grant from Zcash Community Grants (formerly called ZOMG) or ZF?


Are you seeking or have you received funding from other sources for this proposed project?


Applicant background:

Christopher Allen is the coauthor of the TLS and DID standards and is currently working with the IETF to advance dCBOR and the Envelope data format for standardization. Recognized as a “Top 100 Influencer in Identity,” he was Principal Architect at Blockstream, Vice President at Blackphone, and CTO of Certicom. Today, he is the Executive Director of Blockchain Commons.

Blockchain Commons has been working for almost five years on bringing together wallet developers across the blockchain ecosytem to create secure & interoperable systems that protect the human dignity of their participants.

Some of Blockchain Commons’ major achievements include the introduction of an interoperable Animated QR specification (Animated QRs - Developer Resources), development of the Lifehash visual hash specification (LifeHash - Developer Resources) and of course the dCBOR (draft-mcnally-deterministic-cbor-07 - dCBOR: A Deterministic CBOR Application Profile) and Envelope structured data formats (draft-mcnally-envelope-06 - The Gordian Envelope Structured Data Format) for the IETF. More information on Blockchain Commons’ extensive recent work can be found in the 2023 Yearly Overview (Blockchain Commons 2023 Overview - Blockchain Commons) as well as overviews from previous years (Posts by Tag - Blockchain Commons).

Description of Problem or Opportunity:

Private key material and the seeds that generate them are threatened by loss and by theft. Methodologies such as Shamir’s Secret Sharing have offered some proof against loss, but seeds and keys are still threatened when they are reconstructed.

Newer methods such as Verifiable Secret Sharing (VSS) and Distributed Key Generation (DKG), which are available as part of ZF FROST, offer next-generation solutions to these problems, notably decreasing the threat level. For them to become a reality, FROST development needs to be finalized and standardized, and real-life references need to be created to show developers the possibilities.

Since VSS and DKG are available in the ZF FROST libraries, highlighting their usage offers Zcash the opportunity to be seen as a leader in the entire blockchain ecosystem, creating new interest in Zcash and its blockchain.

Proposed Solution: Describe the solution at a high level.

Blockchain Commons already has a set of reference libraries, CLI applications, and other tools that demonstrate the usage of classic Shamir’s Secret Sharing. We want to expand it to include VSS, Trusted Dealer Generation, and eventually more, all drawn from ZF FROST.

But the initial goal is to make ZF FROST’s VSS solution fully available to wallet developers. It builds on our long-standing work with over a dozen wallet developers who have implemented interoperable Blockchain Commons specifics such as Uniform Resources (URs) and Animated QRs (see: UR Implementations - Developer Resources). Though the ZF FROST library is an excellent reference library for cryptography, it’s not quite ready for wallet use; we want to contribute our knowledge and our work with the wallet ecosystem to make that possible.

By empowering wallet developers to use ZF FROST, we can expand the ecosystem that’s aware of Zcash to include a wide variety of developers. Down the line, we plan for standardization of the new protocols to expand that recognition even wider. The ultimate goal is to have VSS protecting not just blockchain assets, but SSH keys, COSE data, Gordian Envelope data, and more.

This process will be broken into six large phases. Though this proposals suggests advancement through all of them, a smaller budget could allow for progress through just the earlier stages, allowing for assessment of initial milestones before continuing work.

  • Phase One: Identify a broad base of open-source developers working with FROST, not just those releasing libraries. Organize at least two Round Tables to allow FROST developers to communicate their trials and triumphs working with the technology, and fully document those Round Tables.

  • Phase Two: Create a 2.0 release of Blockchain Commons’ security-reviewed SSKR library that adds ZF FROST’s Trusted Dealer Generation methods, offering an alternative to traditional Shamir’s Secret Sharing.

  • Phase Three: Acquire a new security-review of updated library.

  • Phase Four: Review the wide variety of formats for public and private keys, incuding classic 33-byte public keys (as used by Zcash), modern Bitcoin x-only public keys, formats for storing keys on disk, formats for storing keys with metadata, and methods for deriving child keys. Write a specification that integrates those with VSS and Trusted Dealer key formats.

  • Phase Five: Expand Blockchain Commons’ existing reference CLIs, keytool and seedtool, to include VSS from ZF FROST and standardized key formats from Phase Four. (Possibly extend envelope-cli as well, if there is interest and reason.)

  • Phase Six: Further expand reference CLIs to offer keys on other curves, such as the 25519 and Ristretto curves usable by ZF FROST.

Solution Format: What is the exact form of the final deliverable you’re creating?

  • Phase One: Full documentation of FROST Round Tables, similar to the documentation of a preliminary meeting we held in November 2023: FROST Round Table I: Overview - Developer Resources. Also, an overall summary including a community map of who’s involved in FROST at various places and who’s been missing from the Round Tables.

  • Phase Two: SSKR 2.0 Reference Library that includes VSS created by Trusted Dealer Generation in ZF FROST library.

  • Phase Three: Security review of SSKR and updated SSKR 2.0 Reference Library for any security problems detected.

  • Phase Four: Specification of key data formats, such as an Internet Draft for IETF and/or CBOR object listing for IANA, as well as initial submission to the appropriate standards organization.

  • Phase Five: Updated keytool and seedtool apps (and possibly envelope) that allow for sharding, verifying, and reconstructing keys using VSS and ZF FROST Library as well as usage of new key format.

  • Phase Six: Updated envelope, keytool, and seedtool apps (as appropriate) that support 25519 and Ristretto keys.

Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!

Our standard workflow at Blockchain Commons is to: (1) identify problems faced by digital identity & asset holders and the wallet community; (2) write specifications to address those problems; (3) revise specifications with community feedback; (4) write reference libraries to support the community specification; (5) write reference apps to exercise our reference libraries; (6) advance specifications into standards; and (7) revise specifications, reference libraries, and reference apps for evolving standards.

For this ZF FROST-focused VSS project, we feel the project is already hovering between steps (2)-(4) of this process. There is a reference library, and work is being done to create an informational RFC for the IETF.

Blockchain Commons wants to advance work beyond this stage, creating a more developer-friendly reference library (4), expanding our reference apps to exercise the new VSS functionality (5), and working with IETF to transition FROST work and new specifications to the Applications & Real Time [ART] area (6-7). (The IETF Security [SEC] area has largely ignored multisig to date, and so we don’t find it a viable path for advancement.)

As part of our technical process we will also ensure that our work is future-proofed, particularly so that it can support Distributed Key Generation in a future iteration of the project.

Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?

This project is primarily dependent on ZF FROST (GitHub - ZcashFoundation/frost: Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures) by the Zcash Foundation) and Blockchain Commons’ own SSKR reference library (GitHub - BlockchainCommons/bc-sskr: Sharded Secret Key Reconstruction (SSKR) reference library in C) as well as our keytool (GitHub - BlockchainCommons/keytool-cli: Cryptocurrency key & address derivation for the command line) and seedtool (GitHub - BlockchainCommons/seedtool-cli: Cryptographic Seed Tool for the command line) CLI apps. Both ZFFROST and the original C++ version of SSKR have been security-reviewed, so we think that together they offer the opportunity for a production-ready VSS solution. The goal is to make that immediately usable via the expanded SSKR library.

We expect that that ZF FROST engineers will remain involved in our additional Round Tables, as they participated in our first round table in November 2023 and multiple participants requested we hold more. They should also provide some review of our work to ensure that it remains consistent with ZF FROST. More support would be lovely, but those are the only requirements.

Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?

We will be freshly working with the ZF FROST library and we’re currently unaware of its limitations or dangers, so that’s likely to be the largest obstacle. However, as the first library to offer a security-reviewed VSS, the ZF FROST library is a critical addition to the whole blockchain ecosystem, and we think it’s worth that effort.

Different opinions on FROST usage could cause disagreements on how to advance on specifications. However, our preliminary FROST Round Table had a very congenial atmosphere, and we hope that maintaining that through additional Round Tables will be beneficial for the whole project.

When we get to the expansion of our own CLI apps, the two older tools, keytool and seedtool, will first need to be transitioned from C/C++ to Rust. Since we’ve previously transitioned other work in this way, we consider it a known problem, but obstacles are always possible in this sort of work.

Finally, work with standards bodies can always add arbitrary obstacles to a project, but that lies somewhat outside the scope of this project, whose intent is to lay out a specification and begin the process. Pushing new key specifications through the entire standardization process could be an additional seventh phase after this initial work. It’s a phase that we have more than 30 years of experience with, including recent work with the IETF on the dCBOR spec.

Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.

Obviously, Trusted Dealer Generation is a transitional intermediary mechanism for key/seed security. We like it as a crucial first step before eventually transitioning users to Distributed Key Generation because it’s easy to implement now in current systems. The danger is that VSS might be considered an end solution, robbing developers of the ability to later advance to DKG.

There are also approaching DKG solutions that may have different properties, STORM prime among them as it’s explicitly not publicly verifiable. These differences could cause issues with early solutions such as this one. For example, people may begin building solutions depending on publicly verifiable VSS, and then be unable to move on to a version that doesn’t have that property. (We are tracking this issue in particular, and hope to have a presentation on STORM at a future Round Table.)

Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?

  • Phase One:

  • Full reports of at least two additional FROST Round Tables, including qualitative discussions of what FROST developers are feeling about the technology and what obstacles they’re facing.

  • Published overview of ecosystem.

  • Phase Two:

  • GitHub release of SSKR 2.0 with ZF FROST VSS, plus backport of Rust content into C API for use with Swift.

  • Phrase Three:

  • Successful security review of updated SSKR library.

  • Phase Four:

  • Specification of Key Data Format.

  • Report-outs on any meetings held to discuss Key Data Format.

  • Phase Five:

  • GitHub release of Seedtool, converted to Rust, with VSS output.

  • GitHub release of Keytool, converted to Rust, with new key-data-format output.

  • Optionally, an update of Envelope-CLI if new key-data-formats or VSS seem appropriate for inclusion.

  • Phase Six:

  • GitHub release of Seedtool and/or Keytool as necessary to support keys on the 25519 and Ristretto curves.

Hardware/Software total budget:

$0.00 USD

Please provide justification for the total hardware/software budget:

No hardware or software needed.

Services total budget (cloud, hosting, etc.):

$0.00 USD

Please provide justification for the total services budget:

Any services will be trivial in overall budget.

Compensation total budget:

$157600.00 USD

Please provide justification for the total compensation budget:

This covers architect, administration, engineer, and technical writer time for this project, as well as overhead to keep Blockchain Commons running while we focus on this. Estimated cost is $100 an hour across the board, times 1.5 for overhead.

For the security review of the SSKR library (Milestone 3), cost is solely based on third-party cost of a security review.

Here’s the breakdown:

MILESTONE 1. Each round table is estimated at 8 hours for each of the three core team members of Blockchain Commons, for prep and attendance, plus 8 additional hours total afterward for recording. There are two meetings planned, so 32 hours total x 2 = 64 hours.

MILESTONE 2. This expansion of libraries is specced out at six man-weeks, which is 240 hours. We expect this to be mainly engineer time. It includes review of the Trusted Dealer portion of ZF FROST and integration of VSS into SSKR 2.0.

MILESTONE 3. Our cost for a full security review of the SSKR library previously was $10,000 with Radically Open. We are presuming a similar cost; if preferred the actual cost can be paid directly to the security reviewer rather than to Blockchain Commons.

This milestone also includes 40 engineering hours for discussing the security review with reviewers, researching issues undercovered, and resolving them.

MILESTONE 4. Our production of a key format and our first presentation is estimated at 80 hours, mostly research, architecture, and engineering.

MILESTONE 5. Our updates of the keytool and seedtool apps to Rust and to incorporate VSS functionality is estimated at six weeks of time (240 hours) to maintain the full functionality of both tools (limited functionality could be accomplished in less time).

MILESTONE 6. Our updates of the keytool and seedtool apps to incorporated 25519 and Ristretto is estimated at eight weeks of time (320 hours).

Do you require startup funding?


Milestone 1 - estimated completion date:


Milestone 1 - USD value of payout upon completion of deliverables:


Deliverable 1.1

Phase One. Two FROST Round Table meetings, with full documentation and recording, as with our preliminary meeting. The meetings are expected to be completed by 6/30/24, full deliverables done by 7/31/24.

Milestone 2 - estimated completion date:


Milestone 2 - USD value of payout upon completion of deliverables:


Deliverable 2.1

Phase Two. Updated SSKR library with VSS from ZF FROST.

Milestone 3 - USD value of payout upon completion of deliverables:


Milestone 3 - estimated completion date:


Deliverable 3.1

Security reviewed SSKR 2.0 library in Rust. We can’t guarantee the timing of this milestone because it will depend on a third party for the reviewing.

Milestone 4 - USD value of payout upon completion of deliverables:


Milestone 4 - estimated completion date:


Deliverable 4.1

Specification for key data format. Initial submission to standards organization. we expect this to be informed by the first milestone (meetings) and to occur in parallel with the next two (production & security testing of SSKR 2.0).

Milestone 5 - estimated completion date:


Milestone 5 - USD value of payout upon completion of deliverables:


Deliverable 5.1

Updated versions of keytool-cli and seedtool-cli for Rust + VSS.

Milestone 6 - estimated completion date:


Milestone 6 - USD value of payout upon completion of deliverables:


Deliverable 6.1

Updated versions of keytool-cli and seedtool-cli for 25519 + Ristretto.

Total proposed USD value of grant:

$157600.00 USD

How was the project timeline determined?

The project was carefully broken down into phases, and the time costs of each phase were estimated based on experience.


Hi @BC-Shannon - Welcome to the forum, and thank you for submitting your grant proposal! We will review it in the upcoming weeks and reach out if we have any questions.

In the meantime, if you have any questions for us, you can post them to this thread or DM us at @ZcashGrants.

Zcash Community - We want to hear your feedback on this grant! You can post your comments to this thread or DM us at @ZcashGrants if you’d like to provide feedback in private.



Hmm… I don’t see the part where there is “Wallet Integration”. Am I missing something?


Do you need help or a support team ??

1 Like

In Phase Two we update our existing secret-sharing library, which is used by wallet manufacturers, and in Phase Three we security review it, which together should allow its use in production wallets.

This is the libraries we’re discussing, including two conversions by some of the wallet folks we’ve worked with:

(Blockchain Commons is fundamentally working with manufacturers and other folks in the ecosystem to support them with specifications, libraries, and tools, though we also have our own reference apps, such as Gordian Seed Tool.)

1 Like

Personally, I don’t see the issue with using the ZF crates directly.


What Blockchain Commons offers the wallet developer community (mostly currently Bitcoin wallet developers) are layers of libraries/crates that allow for interoperability for various higher level functionality.

Currently our most broadly deployed interoperability (with over 13 bitcoin wallets using it) is enables signing PSBTs (Partially Signed Bitcoin Transactions used by multisig transactions) via QR codes (with optional animation as often PSBTs are larger than what can be parsed by a primitive laptop camera, or displayed by a constrained hardware display). You can see a quick video demonstrating this at https://www.youtube.com/watch?v=HsFF5HPKQIk

To to this there are many layers, MUR (multipart URs, which is what breaks up for animation with fountain codes for reliability), URs (an encoding optimized for QR compression but works with other transports such as NFCs, URL, Tor, etc.), dCBOR (a deterministic version of the binary encoding version of CBOR), the particular PSBT decoding to get the public keys, finding the private keys that can participate in PSTB, then present metadata to the UX for approval to sign the PSBT with the local key, then signthe PSBT with that private key, transforming the result back into dCBOR, back to UR, then to MUR, and finally to the animated QR to return the PSBT to the requester.

All of our successful interoperability standards have multiple layers Our long term goal is that the whole architecture is updated so that if it is discovered that one of the keys is FROST public key, that various requests (which may or may not use QR, NFC, Tor, etc.) can resolve and sign the request, with all of the metadata pass appropriately to various FROST signing services.

Another emerging interoperability standard is how to reliably backup secret key material, currently mostly cryptographic seeds and metadata on how to derive final keys to them. One of the methods of backup is to use a well-defined (and security reviewed) SSS-based SSKR tools to shard the keys and metadata, in an interoperable way, so that they can be restored in another wallet, which might be from another company. We’d like to move SSKR from SSS to VSS, which allows shard-holders to possibly participate in signing operations, not just recovery operations. We also want to be able to backup FROST shares that we may have participated in and thus have something that isn’t quite a delicate as a private key or seed, but does require resilience.

As you can see, we have success in supporting multiple wallet developers to support these kinds of layered interoperability, that preserve the choice and autonomy of the user to move their data to the tools they prefer to use, rather than be locked into the choices of a single wallet developer. We’d like to serve that role to offer FROST capabilities to the bitcoin community, and offer these kinds of layers to other communities that use FROST.

For instance, wouldn’t it be nice to see an initial QR on a web page or a hardware device, or an NFC card, that request you to participate in key creation ceremony? You scan the QR, approve the TOFU, and eventually you have your FROST shares, sufficient details the other parties you need to collaborate with to sign, policy metadata for what your role in that quorum is (are you a primary signer and need high assurance before signing, and or high availability? You’ll only sign last? You are only a signer of last resort?)

Later, when you need a signature from the quorum, you have all the metadata to make the request, send for approval via QR, NFC, URL or Tor (with anti-correlation and privacy built-in), and after approval, get a final QR with what you need to broadcast the signature, or sufficient errors to know why it failed (lack of approval for metadata reasons, lack of quorum, time out, etc.)

We are an open development organization, and currently host monthly meetings of wallet developers supporting interoperability. We welcome your participation in these meetings, to help set our priorities, and contribution to, and review of, our code. We also hosted the first FROST Implementers Round Table, which also included developers of the FROST code bases FROST Round Table I: Overview - Developer Resources as we’d also like to see interoperability at this layer as well. Currently each have made choices that are slightly incompatible with each other. We’d like to make sure that if these can be addressed, they are not overlooked.

As you can see, Blockchain Commons is looking at the big picture. We’d like support from the Cash Foundation to continue to do so. We’d also appreciate financial support from individual, developers, and organizations through GitHub sponsorship.

– Christopher Allen

This is our first proposal to the ZF, and we have not been involved in the zCash cryptographic community to date. Our major connection is that both the Bitcoin and zCash communities are moving toward support FROST, and there are very opportunities to also use FROST with IETF and W3C standards, both of which we are involved in.

Obviously many of my thoughts above are beyond the initial grant proposal requested, but I hope it gives you a better view of what the big picture is.

However, if there is something else that you’d like to see as a priority within this big picture, we welcome suggestions on either how to add it to our current proposal, or make another proposal.

Do you mean that by “wallet integration”, you mean “providing wrappers for other wallets so that they can integrate”?
Though I can see the benefits to FROST adoption, I am not sure it directly benefits Zcash so much.
Good luck for your grant.

1 Like

Agree. @ChristopherA you are clearly technically accomplished, but I see this grant as another Arti: A pure-Rust Tor Implementation for Zcash and beyond.

We need more focus on achieving our own goals vs. the broader ecosystems’ (read: we need to be more selfish).


This is the kind of message I like to read!


Clearly the Zcash Foundation has found it useful to support the ZcashFoundation/frost implementation, as well as support having a major security review of it. I can’t speak to the Zcash roadmap, but I presume that there is some utility there for the Zcash ecosystem.

There are also many parts of FROST that are useful for wallets in general, including Zcash wallets. For instance, as part of FROST key generation means that you don’t have the requirement to trust a single to properly create a key – you only need a single party to be honest. Though this can used for aggregatable multisig (for instance on Bitcoin), it can be used in other ways. For instance you could have three, heterogenous implementations (say three hardware devices) create parts of a key for you, in a very safe way (and not to have to fully trust your own hardware), and then you can assemble (this is the VSS used by FROST). This allows for some a number of interesting to help make wallets more resilient, more secure, and more private.

Finally, much of our developer stack is broadly useful for any cryptocurrency that wants to either implement air-gapped systems, or multisig. Though most of our wallet developer patrons use it for Bitcoin, they also use the same developer stack for an Ethereal and a Tezos wallet. I would presume that any Zcash wallet developer might find these same capabilities useful as well.

So I don’t think our grant proposal is as far off from “achieving our goals” as you might think. Yes, it is not core to the Zcash roadmap, but very useful for the Zcash ecosystem.

– Christopher Allen


Chad, I’m not quite sure I understand the question – is this is about the proposal, or if you are offering to help? I’ll give a first pass answer:

Blockchain Commons is an open development community, but we also know that the best open development also requires funding. We can’t fully rely on volunteers – to get the best job done, especially in cryptographic code and protocols, we need to be able to pay people. Thus this grant proposal.

But we also know that we need to grow the professional ecosystem, so we have sponsored 3 sets of group internships, and coordinate the work of a number of volunteers for maintenance and research. Right now in particular we are looking for volunteers who are excited about FROST, or have a greater knowledge of the Zcash ecosystem, or are interested in advancing the security and reliability of hardware wallets. From these volunteers, we plan to find some that we fund for some for larger scale projects.

I hope that answers your question, but if it doesn’t, I’ll be glad to offer more clarity.

– Christopher Allen


Hi BC-Shannon,
Hi ChristopherA,

I enjoy your interest in Frost wallet integration and the willingness to take a leadership role on the edge. Your proposal is nice to read, however what is always at the front of my mind, who specifically is going to use your finished solution, how are you going to capture the attention of who you plan on targeting from competing solutions? How many end user (I assume developers) can you really capture and maybe I missed it but I don’t see any funds allocated for this activity? Can you help?

1 Like

Our organization is focused on serving developers, who more directly serve the customers. We help coordinate the “co-opetition” — each has a niche, but they also need to work together to serve their customers who are concerned about vendor lock-in. We currently have monthly meetings of the Gordian Wallet Community on a wide variety of subjects — last month was about our new Gordian Request / Response functionally (Gordian-Developer-Community/meetings/2024/03-06/presentation-rr.pdf at master · BlockchainCommons/Gordian-Developer-Community · GitHub) that reduces complexity of complex tasks, especially with multisig wallets. In our UX analysis of one common multisig scenario, using it reduced user decisions from 5 to 2, research points from 11 to 1, human actions from 31 to 14.

Our ongoing support of the wallet community is isn’t part of this grant request, but it is part of why we think the ZF should support our work in general. For instance, this same Gordian Request / Response is useful for any wallet that needs to work with other wallets or coordinators.

We do have in our proposal to fund additional FROST Workshops, like the we offered last year, in order support collaboration between teams (not just the ZF FROST team, but other teams working on this emerging tech) to share new features and evangelize best practices for using FROST.

– Christopher Allen


We could add to this proposal a specific series of workshops for Zcash Wallet developers useful for their needs for interoperability and reliability, share what from the various specifications and protocols they might be able to leverage immediately, and brainstorm what specifics might have to be adapted to support the Zcash Wallet communities needs.

– Christopher Allen

1 Like

“specific series of workshops for Zcash Wallet Developers”

Great, in order to build more content and preserve content capacity for future users:

Would you be willing to produce a short video of the content of one of your workshops to be distributed on zechub.xyz ?

Would you be willing to conduct an interview on free2z live to explain the importance an use cases of frost wallet intergration?

Would you be willing to write a brief introduction and basic demo document to be added to Zcash Read the Documentation ?



@BC-Shannon Thank you for your submission. After consideration from @ZcashGrants and sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal.

The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward, both here on the forum and in the below avenues as well:

The committee strongly encourages you to remain engaged with our community!


All of our meeting videos are publicly available on YouTube at https://www.youtube.com/channel/UCPQ9LtDWZAkfItMF4B5tztw and presentations and transcripts are available at Gordian-Developer-Community/meetings at master · BlockchainCommons/Gordian-Developer-Community · GitHub. Everything we do is open licensed, so there is no reason why you can’t also cross-post any on your site.

Our grant proposal regarding FROST was turned down, so I’m still not quite sure what the Zcash Foundation’s roadmap for FROST is. I thought at least they would support continued FROST Implementers Round Tables, as our last was success.

In the meantime, our next regular Gordian Wallet Developers meeting in April features Jesse Posner, who is working on the secp/ZKP FROST implementation (FROST by jesseposner · Pull Request #138 · BlockstreamResearch/secp256k1-zkp · GitHub), who will be doing a presentation on his work, in particularly for Bitcoin developers. However, commentary and thoughts from other developers would be very welcome, so we hope anyone interested in FROST will join us.

This meeting will be on Zoom:

Topic: Gordian / FROST Joint Meeting Time: Apr 3, 2024 10:00 - 11:30 AM Pacific Time (1pm ET, 7pm CET) URL: Launch Meeting - Zoom

Specific to your group, probably better is a topic to demonstrate what various Bitcoin wallet developers are doing on interop, in particular with air-gapped QRs, to see if there is interest by Zcash wallet developers to participate in these standards.

At this point there it isn’t clear the Zcash ecosystem is interested in wallet interoperability. We are seeking weak signal to see if they are (thus this last grant proposal). Thus it is hard to prioritize any specific additional work as a priority. However, if there are some other useful works that make sense to cross-post, we will.

We also could use your help in understanding how to navigate this grant system. If you have some ideas on what we should propose as a new grant that also meets your needs, let me know.

– Christopher Allen

1 Like