Grant Application: Konclave (taking the viewing key off the coordinator)

Summary. We ask for USD 18,000 in three milestones, each paid only after the committee accepts the delivery. 1) Measure scanning and proof generation in the browser of real phones, with an independent design review chosen by ZCG. 2) Build new vaults where the viewing key is created and kept only on the members’ devices. 3) Upgrade existing vaults to that model where possible and publish the pattern. Today the participants’ devices sign; scanning, balances and building and proving the transaction run in our hosted service, which holds each vault’s viewing key. This grant does not change that the coordinator still stores member names and proposals until issue 601. Nothing here is retroactive.


Hi everyone. I am Daniel Gorgonha, co-founder of DeegaLabs and technical lead of Konclave. I am writing this topic alongside my co-founder, Dayane Bismark, who had the original idea of the project and leads the product, narrative and communications fronts. This is our first application for a Zcash Community Grants grant, and we want to present the proposal clearly.

Konclave was born at ZecHub Hackathon 3.0 with a clear goal: to create a human layer over the Zcash Foundation’s threshold tools, removing the need to use command lines and paste hexadecimal codes by hand. We built a treasury solution for groups that move ZEC, such as companies, communities, nonprofits and grant-funded teams.

In Konclave, any member proposes a payment or a payroll, the others approve and the devices sign together using FROST. A payment needs the approval of t of n members, and each member’s device checks the payment before it adds its signature. A payroll serves several beneficiaries in a single shielded transaction, accompanied by encrypted payslips in the memos. For those watching the network from outside, each payment is an ordinary shielded transaction; for the group’s members, all the proposals, votes and ledgers are transparent. The platform runs directly in the phone’s browser and is already in operation on mainnet with 20 validated transactions (the most recent, a payroll in production carried out on 2026-10-04). Zcash Brasil acts as our pilot group.

We have an important privacy bottleneck that we want to solve before organizations trust larger treasuries to Konclave. Today, to scan the blockchain and display balances, our coordinator needs to hold the full viewing key of every vault. This means the server can read the history of all groups. It holds no share of any key. Until issue 567 is fixed, a payment signed by the quorum is only as safe as the coordinator itself. For that reason, our security notes recommend not keeping significant funds in the app yet.

This application requests $18,000 split into three milestones, paid only after the acceptance of each deliverable:

  1. Measure the scanning and proof generation costs in the browser of real phones and have the architectural design reviewed by an independent specialist chosen by ZCG.
  2. Build support for new vaults, where the viewing key is created and kept only on the members’ devices.
  3. Upgrade the existing vaults to that model, in place where possible, and publish the specification of the pattern to guide other Zcash teams that keep viewing keys on servers.

What this grant does not change: the coordinator still stores the members’ names and every proposal, with its destination, amount and memo, until a later step that seals them (issue 601).

We emphasize that no part of this request is retroactive. Everything we have delivered to date was financed with our own time and resources. Our commitment to the ecosystem is long term, which means we will keep building Konclave regardless of the approval of this funding. The grant will cover specifically the engineering hours needed to execute these three milestones, allowing us to focus fully on this solution so that it reaches the community sooner.

All the security defects and limits that we have publicly disclosed were found by our own reviews (including issues of privacy, denial of service, malleability and key storage in the browser, tracked in their respective issues in the repository). It is precisely because we recognize the limits of the view of those who build that we insist that the review of this grant be conducted independently and published in full.

Konclave is built on the Zcash Foundation’s infrastructure. We credit projects such as Zkool, Zafu and CYZE, which, by their own descriptions, already keep the viewing key on the device. What we add to this ecosystem is the governance and treasury structure. If you maintain WebZjs, operate wallets with keys on servers, or already have measurements of scanning and Halo 2 proofs on mobile devices, we would love to hear your impressions and contributions in this topic.

Transparency statement: Our pilot group, Zcash Brasil, has an approved ZCG grant (ZCG issue 155). Neither the organization nor its leader receives any fraction of the resources of this request. Konclave is also entered in the Zcash track of Colosseum’s Crypto World’s Fair, an event funded by ZCG.

Thank you for reading, and we are available on the forum to answer any questions.

GitHub issue: Grant Application - Konclave: taking the viewing key off the coordinator · Issue #486 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

Daniel Gorgonha, DeegaLabs

It seems to me that you are moving towards to decentralized design.

  1. Now, the coordinator prepares the tx (a) and orchestrates the FROST ceremony (b).
  2. You want to move (a) to the participants. But then as you see, the communication of the tx is tricky. It should be encrypted otherwise the coordinator knows too much. How do the N signers agree on the key?
  3. It seems easier to move the coordinator role (b) to one of the peers since it’s a crate.
  4. By now, the coordinator is simply relaying messages. Yet, the message metadata leaks privacy.
  5. Maybe the best is for the peers to talk to each other p2p?
1 Like

Thanks, @hanh. Taking your points in order.

On (b): in the web app the FROST coordinator role already runs on a member’s device, not on a server. Every signer contributes a share, and one member’s device also assembles the signing package and aggregates. The hosted service does (a): it builds the transaction the group signs, hands it to the devices, and takes the finished signature back to apply and broadcast. The relay in the middle only carries messages. Today the hosted service also holds each vault’s viewing key. That key is what the service can read, and taking it off the server is what this grant is for.

Moving (a) to the devices means scanning, building and proving on the phone. We have not measured that yet. Milestone 1 measures scanning and proving on real Android phones and a laptop, and the design that follows depends on those numbers, so we do not promise the outcome before we have them. For the encrypted channel you mention, sealing to device keys already exists; the plan is for the viewing key to be created on one member’s device and sealed to the others, so it never reaches the coordinator.

On the metadata: signing requests are sealed to the members’ device keys, so the relay does not read them once every member has registered a device. Until then the request goes out unsealed. The relay still sees room names, message sizes and timing, the IP addresses of whoever connects, which seats take part in a signing round and when, and, while a vault is being created, the member names, the vault name and the quorum in clear. Rounds by QR or copy-paste would take the relay out of the path. That is on our roadmap as planned and not built, and it is not part of this grant. Peer to peer is not on our roadmap today, and I would like to hear how you would carry it.

On how the signers agree on the key: for vaults created since v0.12.0 it is a DKG across the members’ devices, and the members compare a short code out of band before the vault is used.

If it helps, I would be glad to compare notes on the coordinator crate and on message transport.

That’s what mobile wallets do today, don’t they? What else is there to measure?
Are you saying that currently the participants don’t have the wallet functionality?

1 Like

Fair challenge, @hanh, and you are right that native wallets do this today. Two direct answers.

Do participants have wallet functionality today? Not the part that finds funds and builds the payment. A participant’s device holds its share, shows and checks a payment, and signs. Scanning, balances, and building and proving the transaction run in our hosted service, which is also why that service holds the vault’s viewing key today. The browser never scans. Moving that work to the devices is what this grant is for.

What is left to measure? Wallets like yours scan and prove on phones today. Konclave runs in a browser, so the open question is whether the same work is acceptable in WebAssembly on mid-range Android, with the current libraries and the Ironwood pool. The public number we start from is the benchmark ChainSafe published: an Orchard proof in 5.4 seconds on a 2023 laptop in Firefox, with four threads. Our own estimate for a single-threaded proof in a browser is 60 to 120 seconds, taken from published figures for a comparable circuit. We have not measured it, and we have not measured any phone. That gap, between 5.4 seconds and our estimate, is what Milestone 1 would close, and it decides whether the answer is the browser or something else.

If you, or anyone, have WebAssembly scanning or proving numbers on Android, we would use them. We would propose narrowing the measurement part of Milestone 1 to what is still unknown, here on this thread, and say exactly what changes before anything is measured. The design and the independent review stay as filed.

All your responses are 100% AI generated, so I am doubtful that you have done actual measurements.

I write in Portuguese and use an AI assistant to help me write and translate into English. On measurements, we have not made any yet: that is what Milestone 1 is for.

We hadn’t measured it when you asked. Now we did. One 2-action proof, in WebAssembly, single thread, no server, verified.
Galaxy S24 Ultra: 17 to 35 s. Galaxy A72 (6 GB): 49 s. Galaxy A14 (4 GB): 132 s on Firefox, 279 s on Chrome.
Synthetic transaction, not a real vault. Scanning not measured yet, and a payroll with many payees will cost more. Raw output and code: GitHub - deegalabs/konclave-prove-poc: Orchard and Ironwood proving in WebAssembly on a phone: a measurement harness and its raw results · GitHub . You can run it on your own phone: Konclave proving PoC
What time would you call acceptable on a phone?

@danielgorgonha at the most recent meeting, ZCG voted to approve this proposal. Congratulations!

To keep the community informed, ZCG requests that you provide monthly updates via the forum in this thread.

Please check your forum inbox for a direct message from FPF with important next steps, including a link to the Milestone Payment Request Form and your unique validation code for submitting payment requests.

2 Likes

Thank you, ZCG. We will post the monthly updates in this thread.

1 Like

@ZCG, a question for the committee, as FPF suggested.

The application includes an independent review of the Milestone 1 design, chosen by ZCG. Who does ZCG want as the reviewer, and how do we reach them?

Work on Milestone 1 has started.

Thanks,
Daniel

I believe the ZCG allows independent audits and reviews, but not necessarily the one ZCG uses, because Least Authority is NOT affordable for a (relatively) small project… especially in a $18K total budget.

Other projects such as Zcash Names used other independent reviewers and auditors AFAIK (We audited them!)

Again, @ZCG should confirm.

1 Like