Zecboat’s opportunity is to provide a lightweight, purely cryptographic L2 infrastructure stack. Zecboat creates Orchard-secured asset collections and allows users to lock SOL and instantly mint private representations on Zcash via our dedicated zebrad fleet and viewed on Zecboat’s Desktop Client. This brings immediate, usable liquidity to the Orchard pool.
github link: Zecboat Bridge: FROST-Secured Wrapped Asset (wSOL) · Issue #262 · ZcashCommunityGrants/zcashcommunitygrants · GitHub
Dear Zecboat team,
Your grant application mentions the use of FROST coordinator servers for signing bridge transactions. Could you please clarify:
How many coordinators will be in the system?
Who controls these servers? Will they be operated by independent parties, or will they be servers owned and operated by your team?
What signature threshold (M-of-N) are you planning to use?
How can a user be assured that their funds cannot be stolen if M coordinators (controlled by your team) decide to sign a transaction without the user’s consent?
What happens if your coordinators become unavailable? How would a user withdraw their funds?
I understand that centralization may be necessary in early stages, but for an L2 infrastructure that claims “cryptographic security,” it’s important to understand where trust resides: in the mathematics or in your team.
Thank you for your time and clarification.
Hi andreudumitro-eng,
A little clearness in frost, a Coordinator is merely a routing server that aggregates messages; it does not hold any private key material and cannot sign transactions. The Signers, Participants are the entities holding the cryptographic key shares.
A core of this proposal is the Proof of Reserves Dashboard. Because the wSOL asset uses the ZMAP standard, every minted token contains metadata linking directly to this live dashboard.
The dashboard displays:
The L1 Lock, Direct block explorer links proving exactly how much native SOL is locked in our smart contract.
The L2 Mint, the cryptographic Proof of Payment disclosures that sum up the exact circulating supply of wSOL on the Zcash network.
The Peg Status, A real-time, mathematically derived ratio proving 1:1 backing.
If Zecboat were to mint unbacked assets or move the L1 funds without authorization, it would be instantly visible on the public blockchains and flagged by the dashboard. We are empowering the individuals to act as real-time auditors.
The Zcash ecosystem suffers from isolation today. Establishing the core architectural pipeline(L1 Smart Contract → Off-Chain Relayer → L2 Zecboat Minting → Desktop UX). We want to test whether users actually want to hold private wSOL before spending years trying to decentralize the validator set. The plumbing works and the market demand exists. Once the demand is proven,the FROST architecture is already in place to transition smoothly into a staged decentralized model without rewriting the entire protocol.
During Phase 1: Milestone 1 & 2, we are implementing a 3-of-5 threshold to authorize any release of funds from the Vault. Zecboat operates all 5 signer nodes. However, these nodes will be geographically distributed across completely distinct infrastructure providers with isolated access controls.
During Phase 2 (Milestone 3, “Verified Partner” program), our explicit goal is to distribute key shares to independent, reputable entities within a partner network, transitioning control away from Zecboat.
If the Signers become unavailable, fROST guarantees safety (funds cannot be moved without M signatures), but it does not guarantee liveness. If 3 of our 5 signer nodes go offline, the bridge halts, and users cannot immediately withdraw. In the event of a catastrophic infrastructure failure, we would use cold shards to spin up new signer nodes, restore the threshold, and resume processing withdrawals. The L1 SOL is never lost due to server downtime it simply waits for the threshold to be restored.
Zecboat believes the Zcash ecosystem needs usable liquidity now. Providing users with a unique audit capibility by using the Proof of Reserves Dashboard allows us to ship a highly optimized, frictionless UX immediately, while our underlying FROST architecture ensures we have the technical runway to progressively decentralize the vault as the network grows.
Thanks
Thanks for the detailed clarification. This is very helpful.
A few follow‑up questions for my understanding:
On the Proof of Reserves Dashboard — if I understand correctly, the dashboard relies on data from your infrastructure. Is there any plan to make the proof verifiable directly on‑chain (e.g., a periodic commitment published on Solana), so that users could audit the peg without relying on the dashboard’s availability?
On signer recovery — you mentioned cold shards to restore signers in case of failure. Could you share more about who holds those shards and under what conditions they can be used?
On the transition to decentralization — do you have specific criteria (like TVL, time, or community vote) that would trigger moving from Phase 1/2 to Phase 3 with independent signers?
I’m asking purely out of technical interest. I think the bridge is an interesting direction for bringing liquidity to Zcash.
Thanks again for the transparency.
The Proof of Reserves, the solana smart contract balance requires no dashboard. Any user can query the public address directly via their own solana rpc or using solscan at any time. The orchard transactions are fully shielded, the circulating supply of wrapped SOL cannot be scraped from a public explorer. The dashboard’s primary function is to host the cryptographic payment disclosures or specific viewing keys for the minting transactions.
The plan is to publish the batch of payment disclosures periodically. A user can fetch these disclosures and run them against their own local zcash node to independently verify the sum of the minted supply.
In our initial frost implementation, the shares live on our geographically distributed cloud servers. The cold shards are encrypted backups of the key material held strictly by the principals of Zecboat and the staged partner program. They will only be accessed under diaster conditions where liveness is permanently lost.
Premature decentralization before the software is hardened often leads to challenges. Stability in the system should operate flawlessly in production for a minimum of two to four months, demonstrating safety and high liveness. Independent partners will incur costs of running highly secure, high-uptime servers. We aim to show the economic utility of the bridge justifies this operational burden for our partners.
The aim of building this bridge to bring utility to the orchard pool now.
Thanks for your time and thoughts