Hi everyone,
I’m Daniel Gorgonha, co-founder of DeegaLabs, a software engineering studio in Florianópolis, Brazil, with 10+ years of software development behind me. I got into privacy through practice. In a local circle on privacy and community safety, I built Safe City, an app for anonymous neighborhood alerts here in Florianópolis, with the code public precisely so anyone can audit that there is no tracking. That project pulled me deeper into cryptography and privacy tech.
Last year I attended the Ipê Village conference, two days at the hotel in Jurerê. This year I came back as a volunteer and on the architecture track, presented a valocracy project, and spent nearly the whole month at the workshops. At the Privacy House, during the Raycash workshop on building onchain apps with privacy, I met @michae2xl, the first Zcash ambassador in Brazil and one of the sponsors of the event. I was also there for the session by pacu, Zcash’s developer relations engineer, on contributing effectively to the Zcash ecosystem. That talk, honestly, shaped how I approached this project: instead of building something and then showing up asking for support, start by understanding where the ecosystem actually needs hands.
Since then I’ve been getting closer to the ZcashBrazil community, and along the way I built privacy-focused projects like a shielded BTC collateral protocol on Starknet and Cronos Shield, 2nd place among 191 projects at the Cronos x402 PayTech Hackathon. Konclave was born at the ZecHub Hackathon 3.0, where I competed, and I’ve been working on it full time for the last 2 months. I’m here because I believe the right way to be part of this community is to create real value and to listen, and that’s what I intend to do.
So here it is, and I’d genuinely value your feedback.
What we built
Konclave is a GUI for FROST threshold vaults on Zcash: a group treasury where spend authority is split t-of-n across members by real DKG, the key is never reconstituted (at creation or at signing), and every transaction is shielded. Propose, approve to quorum, sign, broadcast, account. In plain language, no CLI.
We built it because the Foundation’s FROST tooling is excellent but, as ZF itself has noted, wallet integration is the missing piece. “Easy multi-sig tools for shielded addresses” is also a named ZCG funding priority, which is what pointed us here.
We learned a great deal from Zkool, by @hanh, which already does shielded FROST and solved real problems before we did. We are not claiming the first FROST on Zcash. What we did differently was take the whole ceremony into the browser, with nothing to install, and wrap it in a treasury flow: proposal, approval, signing, and a book.
What is proven (verifiable, not claimed)
12 mainnet transactions, each a real FROST ceremony with the key never reconstituted. Quorums proven: 2-of-2, 2-of-3 and 3-of-4.
Each one is a first: the first time a capability was proven on the live network. It is not a log of every send; the vaults have made more transactions than that, and the ones that only repeat something already listed are deliberately left out. A row there is a claim you can check, not evidence of volume.
Among them:
- an application-driven quorum payment
- a private payroll: one shielded transaction, N outputs, each payslip in an encrypted memo
- a send from a vault born of real DKG
- the full Orchard to Ironwood cycle under NU6.3, including the first Ironwood-pool spend
- a browser-signed broadcast, two tabs over a blind relay (
3022420a…) - a ceremony across separate physical machines, over the internet: two people in two places, each browser holding only its own share (
aec83baf…, block 3,460,285) - a 3-of-4 vault operated by someone other than me (
b496fc3c…) - and a private payroll on the web path, post-Ironwood: 2 beneficiaries in a single V6 transaction (
7c4c1dd5…)
248 orchestrator tests and 189 UI tests, CI on every push, open source (Apache-2.0/MIT).
You do not have to trust any of this: node scripts/verify-proof.mjs reads docs/PROOF.md and checks every txid against public explorers. The script reads the same document the proof page does, precisely so the two cannot drift apart.
Site: konclave.xyz · Code: GitHub - deegalabs/konclave: The vault that decides together. A local-first, browser-native collective Zcash treasury using FROST threshold signatures. Private on the outside, transparent on the inside. · GitHub
No cryptography was reimplemented. In the browser we run the Foundation’s own crates compiled to WebAssembly (frost-rerandomized and reddsa), plus librustzcash. On the local path we use frostd, frost-client and zcash-sign directly.
Honest limits
The chain does not prove where the signers were, for the same structural reason it does not prove the signature was a threshold one: an aggregated FROST signature is indistinguishable from a single-signer one. The cross-machine ceremony rests on the two operators and the ceremony trail, not on the block.
The hosted helper is view-only, not blind. It holds the vault’s UFVK in order to build and broadcast the transaction, so it sees the movements and the memos. It never receives, derives or stores a share, and the relay that carries the ceremony is a blind mailbox. But the distinction matters and we would rather say it.
Quorum policy and proposal expiry are application-enforced, not consensus-enforced, and we say so in the docs.
Some of the proof txids came from trusted-dealer vaults; the DKG-vault sends and the browser broadcasts came from keys born by real DKG.
The desktop app exists and is signed, but has not been validated on each platform. The macOS build is not notarized and Gatekeeper refuses it, so we have disabled the downloads on the site until that is fixed. The vault runs entirely in the browser meanwhile.
This is beta and under active hardening: the last few weeks have been as much about auditing what already existed as about building, and what we find becomes a public issue before it becomes a release. It is self-custodied software: each member’s key share stays on their own device, and we hold no one’s funds.
Who it’s for
Treasurers who shouldn’t be a single point of failure; cooperatives and community funds that decide together; and NGOs, journalists and activist orgs for whom a transparent multisig is a liability, because it doxes donors, salaries and structure to anyone watching the chain.
What’s next
We’re onboarding a few pilot groups now, and I intend to submit a proposal to ZCG in the next round: evolving Konclave from a proven prototype into a maintained product (cross-device ceremonies, hardening, and real-org onboarding). Before that, I’d rather listen: what would make this genuinely useful to this community? What are we missing?
Thanks for reading. This stands on the Zcash Foundation’s FROST tooling, and we learned a great deal from Zkool along the way.
Credit where it is due: the @zcashfoundation team, and @hanh for Zkool.
Daniel Gorgonha · DeegaLabs