Zecboat Bridge: FROST-Secured Wrapped Asset (wSOL)

Community Grants
1

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

Organization Name:
zecboat.com

How did you learn about Zcash Community Grants:
Zcash Community Member

Requested Grant Amount (USD) 99000

Category: Infrastructure

Project Lead:
Name:kworks Role:lead developer Background:web developer Responsibilities:Pioneer Zcash Layer 2 infrastructure. Zecboat has successfully demonstrated the minting and distributing of Orchard-Secured L2 assets (Cyber-Nomads), and has recently executed a Live Fire test on the Solana and Zcash Mainnets, proving our FROST-secured threshold architecture can successfully bridge L1 liquidity into L2 Orchard-secured assets via the ZMAP protocol.

Project Summary
Zecboat provides the premier L2 privacy infrastructure stack, featuring a dedicated node fleet, an optimized desktop client, and a high-speed wSOL bridge to bring Solana liquidity into the Zcash Orchard pool.

Project Description:
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.

Proposed Challenge:
Zcash has the best privacy technology in the industry but suffers from isolation and lack of liquidity. Existing interoperability solutions like subnets or PoS bridges are heavily bloated, requiring entirely new blockchains or native tokens that take months/years to build and introduce large attack vectors. Furthermore, federated multi-sigs are too slow to keep up with high-speed chains like Solana.

Proposed Solution:
Zecboat is a premium L2 Orchard-secured asset collection creator.
Zecboat acts as an exclusive L2 Privacy Infrastructure Provider, treating the ability to mint Orchard-secured assets as a premium business feature to avoid scam tokens and maintain quality control.
The solution consists of:
Premium L2 Orchard-secured assets
High-Speed Asset Bridge: A cryptographic bridge connecting a fast-finality execution environment directly to Zcash.
Zecboat Desktop App: A lightweight Debian/Ubuntu client for instant interaction with Orchard-secured assets.
Zebrad Fleet: A highly optimized backend fleet of Zcash nodes paired with our custom L2 indexing engine to eliminate sync delays and node connections for users.

Solution Format:
Premium L2 Orchard-secured assets.
High Quality, Smart Contract Execution Environment, Zecboat Desktop Client (Debian/Ubuntu), user-friendly website for zecboat.com, and the operational bridging infrastructure.

Dependencies:
Technical Dependencies: The reliance on the Solana Mainnet and fast RPCs like Helius to catch events, the Zcash Mainnet specifically the zebrad full node software, and the mathematical soundness of the open-source FROST threshold cryptography.
Resource Dependencies: The need for standard cloud infrastructure to maintain the high availability of zecboat’s globally distributed Zebrad fleet, L2 indexers, and the frostd coordinator servers.
Collaborations: Operate independently, the success of the Verified Partner program in Milestone 3 will depend on onboarding partners to test the liquidity demand.

Technical Approach:

  1. Smart Contract Execution: An isolated environment that securely holds external assets and emits state-change events.
  2. Off-Chain Orchestrator: A high-performance listener that monitors external events, dynamically decodes Zcash Unified Addresses (UAs), and triggers the minting process.
  3. Threshold Cryptography Integration: Integrates Zecboat’s custom RPCs to generate a transfer plan and uses threshold signatures to authorize the Zcash minting.
  4. L2 Indexing & Desktop App: A custom indexer parses the L2 state, allowing the desktop app to instantly display and transfer bridged assets.
  5. Zecboat.com provides a user friendly interface to view L2 Orchard-secured asset collections.

Upstream Merge Opportunities:
Zebra and ZcashFoundation/frost. I am running custom modifications/hacks to get the bridge working today.

The new RPC endpoints we built (z_listassets and z_viewasset) that allow indexers to read the ZMAP metadata memos.

If the market and community likes the wSOL asset, ZMAP RPC indexing logic could be merged upstream into official nodes. This would give all Zcash wallets the immediate ability to track L2 assets before native L1 ZSAs are finalized.
The goal is to hit Milestone 1, 2, and 3 to prove market demand first. Upstream merge discussions would realistically begin post-Milestone 3 once the community has validated the asset.

Hardware/Software Costs (USD) $25000.00

Hardware/Software Justification
Funding for L2 orchard-secured asset creations.
Service Costs (USD) $25000.00
Service Costs Justification
Cloud hosting for the Zebrad fleet, L2 indexers, zecboat.com and threshold coordinator servers for 12 months.

Compensation Costs (USD) $49000.00
Compensation Costs Justification
Development time for hardening the Off-Chain Orchestrator, polishing the Debian/Ubuntu Desktop App, branding zecboat.com and implementing the progressive feedback survey of users towards our products and services.

Total Budget (USD) 99000

Implementation Risks
L2 Standard Adoption: Ensuring the community understands that “Orchard-Secured L2 Assets” inherit the exact same privacy guarantees as base ZEC, despite not being at the L1 consensus layer.
Threshold Coordination Latency: Ensuring the FROST signing ceremony between distributed nodes does not introduce unacceptable delays in the bridging experience.

Potential Side Effects:
The success of Zecboat will prove that Layer 2 assets are viable on Zcash today, potentially shifting developer focus away from base-layer upgrades (like ZIP-226) and towards application-layer infrastructure.

Success Metrics:
Active bridging volume between the external network and Zcash.
Number of active users on the Zecboat Desktop App.
Orchard-secured L2 asset collections at zecboat.com
Publication of user experience surveys.
Publication of a security review for the Smart Contract Environment and Off-Chain Orchestrator.

Startup Funding (USD): 5000
Startup Funding Justification:
Cloud hosting, Funding for L2 orchard-secured asset creations, organizational counsel.

Milestone Details
Milestone 1 – estimated completion date: 2 Months from funding Milestone 1 – USD value of payout upon completion of deliverables: $30000.00 Deliverable 1.1 - Production deployment of the Smart Contract Execution Environment. - Launch of the Zebrad fleet and L2 indexers. - Public launch of the Zecboat Desktop App (Debian/Ubuntu). - Launch of user-friendly website and new branding for zecboat.com. Milestone 2 – estimated completion date: 2 Months from milestone 1 completion
Milestone 2 – USD value of payout upon completion of deliverables: $35000.00 Deliverable 2.0 - Activation of the asset bridge for public showcase of the new wSOLzsa asset. - Live deployment of the mathematically verifiable Proof of Reserves Dashboard at zecboat.com/bridge/wsol. - Publication of internal survey results to measure user liquidity demand for private L2 assets. Milestone 3 – estimated completion date: 2 Months from completion of milestone 2
Milestone 3 – USD value of payout upon completion of deliverables: $29000.00 Deliverable 3.0 - Completion of the Smart Contract & Orchestrator. - Implementation of the “Verified Partner” program, onboarding the first B2B partner to the Zecboat L2. - Sustained marketing and community workshops demonstrating L2 asset privacy. Total proposed USD value of grant: 99000.00 USD

Zcash Community Grants Meeting Minutes 4/13/2026
2

Dear Zecboat team,

Your grant application mentions the use of FROST coordinator servers for signing bridge transactions. Could you please clarify:

  1. How many coordinators will be in the system?

  2. Who controls these servers? Will they be operated by independent parties, or will they be servers owned and operated by your team?

  3. What signature threshold (M-of-N) are you planning to use?

  4. 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?

  5. 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.

3

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

4

Thanks for the detailed clarification. This is very helpful.

A few follow‑up questions for my understanding:

  1. 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?

  2. 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?

  3. 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.

5

Hi @andreudumitro-eng,

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

6

Hi Kworks, the presentation about your innovative bridge for solana onto the zcash network was great! In our view it’s clear that there’s a growing demand for a service such as this from an insurance point of view. Is there a way to brand the wrapped solano with our logo and a statement like “insured by xyz”?

7

Yes, absolutely. when creating the metadata for a zcash L2 orchard-secured asset you have full control over the branding and the information associated with it.

We could include an image field in the json metadata. This field could contain a url pointing to your hosted company logo or an image branded with your logo. As well, for the branded statement we could add in the description field such as, “description”: “wSOL is wrapped solana on zcash. Insured by XYZ Corp.” Plus, we could add custom attributes/properties: For a more clear and structured look, you can use an attributes array. Wallets often display these as distinct visual tags or rows.

{
“name”: “Wrapped Solana”,
“symbol”: “wSOL”,
“description”: “wSOL is wrapped solana on zcash. Insured by XYZ Corp.”,
“image”: “https://QmYourLogoHashHere…”,
“attributes”: [
{
“trait_type”: “Insurance Provider”,
“value”: “XYZ Corp”
}
]
}

Thanks for participating. More important thanks for taking the time in joining the community.

1 Like
8

Branded metadata plus an open Solana RPC reserve check is a strong combo. Agents and merchants can verify backing without trusting a custodian’s dashboard. Curious whether the branding fields are pinned at mint or mutable post issuance. Fixed metadata feels safer for downstream tools.

9

The cyber-nomad collection looks good. Great progress so far. Have you run any live bridges on the Solana mainnet yet?

10

Hi @thejohnnycrypto,
They are strictly pinned at mint. By design, a zcash L2 orchard-secured asset’s
metadata like its name, ticker, and logo are cryptographicaly tied to the asset ID upon issuance and is 100% immutable. You are right, this guarantees that users and merchants can safely rely on the asset’s identity without any risk of it being altered post-issuance.

Great question.

11

Hi @George ,
You can verify the mainnet bridge on any solana explorer to verify the locked SOL.
a) solana address: BPg9arZyyBCSH4KKdnL1XuR937hjotfVhmN9t8cVYKAT
b) first bridging event: the system recorded a lock event locking 1,000,000,000 lamports (1 SOL).
c) zcash UA: The bridged wSOL was successfully initiated for the zcash unified address: u1nz7tj220c5w2vrgpx4edjzjgu4td03l049wawxnz9t9lpjxyuqhkh4f3mm3vp37h6uxqln7h9k98feyk86qwvkaupy9dujcn3u3jlsq0

This shows the ability to build the infrastructure for future growth.

Thanks

12

I like the focus on solving Zcash’s isolation + liquidity problem without spinning up an entirely new chain. Bringing external liquidity into orchard in a usable way is definitely a real gap.

That said, i think the biggest question here isn’t can this work, but what trust model are users actually opting into. Calling it “purely cryptographic L2” sounds nice, but there’s still an off-chain orchestrator, custom RPCs, and a coordinated FROST setup. That’s fine, but it needs to be very clearly definied where trust assumptions begin and end, especially compared to existing bridge designs.

Also the premium asset gatekeeping approach could become a bottleneck if not handled transparently.

If you can clearly prove security guarantees + make the UX dead simple, this could be powerful, but clarity > ambition here, especially for something handling bridged liquidity.

13

Hi @operational-anxiety4 ,

When describing this as a cryptographic L2, zecboat is highlighting the
verification mechanics.

By empowering the user to audit on two separate blockchains by using the proof of reserves dashboard plus the wSOL asset which uses the ZMAP standard, every minted token contains metadata linking directly to this live dashboard. This guarantees that anyone can independently verify the L1 Lock on solana against the L2 Mint on zcash. If zecboat were to create unbacked assets, it would be instantly visible on public blockchains.

The focus on a phased rollout with priority set on building the infrastructure and proving that market demand exists for private wSOL. It would be irresponsibleto ask independent partners (See Milestone 3, “Verified Partner” program) to assume the technical and economic risks of running FROST signer nodes before marketdemand is proven. Once the bridge proves its utility, the FROST architecture is already in place to transition smoothly into a ‘Verified Partner’ network.

Ship an optimized, frictionless user interface immediately, while our underlying FROST architecture ensures we have the technical runway to progressively decentralize the vault as the netwok expands.

Thanks

14

Nice. I think where my mind still goes is the gap between visibility and safety. Detecting unbacked minting instantly is great but from a user perspective, the risk still exists in that window before anything is acted on. So in practice, it still feels like there’s a temporary trust layer around the operator set until the FROST network is more distributed.

That said, the phased approach makes sense. Shipping something usable first and then decentralising is probably the only realistic way to get adoption. I’d just be really curious to see what triggers that transition. Like, is it volume, no. of partners or something else?

15

Hi operational-anxiety4,

Finding deployable solutions for users and verified partners. The transparency of the proof of reserves dashboard that is the necessary trade-off for observing market demand.

The transition to the decentralized verified partner network is driven primarilyby each independent partner and their requirement for economic justification to absorb the infrastructure costs and liabilities of running a FROST signer node will depend on their independent evaluation. zecboat can not determine a verified partner assessment.

The utility of the bridge is proven, the economic incentives align, and we can safely begin distributing key shards fo verified partner.

Thanks

16

Thank you for submitting your proposal. Following a thorough review by the ZCG and a period for community feedback on the forum, the committee has decided not to move forward with this proposal.

We sincerely appreciate the time and effort you invested in your application and encourage you to stay involved and continue contributing to the Zcash community. Further details will be available in the meeting minutes to be posted later this week.

17

zecboat_application
zecboat_application1745×942 288 KB

Here is a look at our upcoming zecboat application its coming along. As well, some individuals who have attended a few of our presentations have asked to view the full cyber-nomad collection. If your interested you can view the full collection at

Thanks

Cyber-Nomad Drop. Claim your Shielded ZSA
18

The rejection feedback indicates a few critical misunderstandings regarding both the technical reality of zcash today and the fundamental difference between trading assets and users holding assets in a the orchard pool. It is important to clarify these points for current and future users.

A) Swaps vs. Private Custody @Artkor feedback
The feedback states that “ZEC already has access to existing exchange infrastructure and cross-chain swap routers,” arguing this negats the need for bridges. This conflates trading with private user custody.

Swap routers like Near Intents or THORChain allow a user to sell SOL to buy ZEC.They do not allow a user to hold Solana exposure within zcash’s orchard pool. Existing bridges primarily exist to drain liquidity from zcash to be used on Solana (minting zZEC SPL tokens).

The zecboat wSOL bridge does the exact opposite: It imports foreign liquidity into the zcash ecosystem. Arguing that swap routers solve this like saying zcash doesn’t need stablecoins because users can just trade USDC for ZEC on Binance.

B) Verifiable Custody vs. Blind Trust @Artkor
The debate that our use of FROST “does not meaningfully reduce the core custody and trust assumptions” because the MVP utilizes a team signer set.

Phase 1 is a Team Model for speed-to-market, the trust assumptions are drastically reduced compared to existing pathways because of cryptographic verifiability.Unlike centralized exchanges where reserves are a black box, the wSOL asset utilizes the ZMAP standard to link directly to a real-time Proof of Reserves dashboard. The L1 Lock on Solana and the L2 Mint on zcash are mathematically provable on-chain 24/7. We are centralizing the signing initially, but the verification iscompletely decentralized and trustless from Day 1.

C) ZSAs Are Live Today @Zerodartz
The feedback states this proposal “is more in the area of what ZSAs would do,
which we know are not going live in near future.”

This is a fundamental technical misunderstanding. The wSOL project does not rely on protocol-level ZSAs. It utilizes the ZMAP (Zcash Memo Asset Protocol) standard, which is live and functioning today inside standard Orchard memos. Zecboat has already executed live-fire bridging on mainnet. The technology is here, and it works and pays big transactions fees.

D) Minimizing Bridge Attack Vectors @Zerodartz
We agree that bridges are prime targets for exploits. That is precisely why we
rejected the standard model of deploying complex, autonomous smart contracts
on both sides. By treating shielded minting as a highly constrained, off-chain
curated service, and entirely separating the “Hot” minting keys from the
“Cold” FROST vault, we have minimized the attack surface that typically
plagues cross-chain infrastructure.

For all zcash users an more importantly for developers building infrastruture for future liquity and grow. Please do not stop. The need and demand is real.