We’d love your thoughts, especially from Zcash developers and privacy-minded users. Feedback, questions, and suggestions are very welcome — thank you for your time and support.
Thank you for your effort to increase shielded Zcash adoption.
When first glancing at your grant application I was surprised by the amount (being only $48000 USD) as the engineering work required for non custodial shielded swaps is substantial.
However after further review I realized this is not an application for shielded non custodial (atomic swap) creation. Based on your whitepaper and grant application it appears your service requires an operator and is in fact custodial (even of the period of custody during the swap process is brief).
Please clarify the custodial/non custodial issue.
If you can create non custodial (shielded atomic swaps) I think the community will be much more excited about your proposal.
Thanks for your thoughtful comment and for raising an important clarification — we really appreciate it.
You’re correct: our current live swap model is not atomic or fully trustless. It is non-custodial in the sense that we never retain user funds, and swaps are triggered based on pre-defined logic as soon as inbound funds arrive — but there is a brief window (seconds) where the operator wallet initiates the outbound leg. So it’s semi-non-custodial under most definitions.
That said, we’re actively exploring mechanisms for trustless or programmable settlement, especially for the Solana side. These include:
Time-locked contracts or transaction pre-signing to ensure conditional delivery
Possible adaptation of HTLC-style logic within Solana’s smart contract framework
Options for on-chain ZEC verification hooks once shielded pool status is exposed via light clients
We’re not claiming full shielded atomic swaps (yet!) — but we absolutely agree that’s a worthy goal. Our aim with this grant is to lay the foundation: get ZEC integrated, verify flows like ZEC → SOL → XMR, and set up infrastructure we can progressively decentralize.
If the community is excited about this, we’d love to make trustless swaps a future milestone — either with additional ZCG support or through external contributors.
I appreciate your thoughtful reply but since you admit the wallet is not fully trustless I stand by my opinion that it is therefore custodial (regardless of the time period for swap completion).
Your proposal states in part:
We will deliver a modular, open-source Python-based swap engine with FastAPI endpoints and CLI tooling to support non-custodial ZEC ⇄ SOL and ZEC ⇄ XMR swaps.
Is there open source code for Solana Blender available? I don’t see anything here:
Since your team will be making fees on the (trusted) swaps following launch why do you see the need for the community to also fund their development?
I would be very interested in seeing a trustless atomic swap proposal from your team. That seems like a much better use of community funds to me.
Thanks for taking the time to engage critically — that’s exactly the kind of dialogue this ecosystem needs.
You’re right to push for clarity around the term non-custodial. In the strictest technical sense, any system where the operator signs the outbound leg isn’t fully trustless. Our current implementation sits in a middle ground: we never retain custody in the traditional sense (e.g. holding pooled balances or requiring a withdrawal request), but yes, there is a short execution window where our swap engine signs the second leg.
That said, we’re absolutely aligned with your perspective that the end goal should be trustless swaps. The architecture we’ve built is intentionally modular and designed with a phased approach:
Phase 1: Functional, non-retentive swap engine with real-time pricing, dynamic fees, and outbound triggers — now live.
Phase 2: Community-reviewed CLI and API toolkit (already built, but not yet published) for self-hosted and audited deployments.
Phase 3: Integration of scriptless scripts, HTLCs, or adapter signatures for atomic swap pathways — likely starting with XMR↔ZEC via tx_extra tagging or ZK-based commit-reveal schemes.
On the repo question: we’ve kept the SolanaBlender source private during rapid iteration and infrastructure hardening. The ZEC module is being separated out and will be published as a standalone open-source engine as part of the Zcash proposal — that’s a firm commitment.
Finally, on the funding point — the request isn’t to subsidize a commercial product, but to help bootstrap public infrastructure that would otherwise be difficult to fund without compromising user privacy (e.g., via venture capital or ads). We’re deliberately not gatekeeping access or enforcing lock-in. The tools we’re building are meant to be used freely, forked, or self-hosted.
We’re happy to collaborate on atomic swap development — if you’re working on something similar, feel free to reach out directly and let’s explore technical overlaps.
Thanks again — this kind of scrutiny only makes the ecosystem stronger.
@Solanblender 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!
Thank you for the thoughtful consideration and for reviewing our proposal.
While we’re naturally disappointed, we remain committed to building privacy-first infrastructure across chains. We still plan to integrate ZEC into our non-custodial swap engine to give users access to shielded transactions—even without grant funding.
Zcash represents one of the most important tools in the fight for digital privacy, and we’ll continue to explore ways to pair it with Solana and Monero in ways that respect user freedom, avoid surveillance, and promote financial sovereignty.
We appreciate the work ZCG does and look forward to contributing more to the Zcash ecosystem in the future.